I’m having a bit of an problem wrapping my head around the task at hand or more so the best way to do it that is.
Take a sample project:
- UI
- DATA (Assembly)
- SERVICE (Assemblies) built onto DATA
Do I put all mappings in the DATA assembly or should I separate them out into the SERVICE assemblies? Or should/can I get rid of the DATA assembly altogether?
This question stems from having an nHibernate static helper class in either the DATA assembly or a UTILITY assembly which is then referenced from the SERVICE assemblies etc.
Project Reference direction
UI > DATA / UTILITY
DATA / UTILITY < SERVICES
UI > SERVICES
Am I just making this over complicated or doing it wrong/right?
Note:
I mentioned Fluent as while I know you can use the config.xml to reference assemblies to map I’m not quite sure how to do that with Fluent without actually referencing project assemblies – which gets me caught in a circular reference loop.
If you are concerned about separating your mapping code from the definitions of your objects (your DATA), you need an additional assembly, a “data access layer” assembly, that references your DATA assembly and contains data access concerns (like your NHibernate mappings). This way, your DATA assembly just contains your POCOs and has know knowledge of persistence. Your data access assembly references your DATA assembly and has knowledge of persistence. I would keep your NHibernate helper methods out of your “UTILITY” assembly and instead put them in this new “data access” assembly.
That all being said, if you don’t care about separating your data from its persistence mechanism, you could just dump everything (mappings and helper functions) in the DATA assembly.