0

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.

Anthony
  • 441
  • 1
  • 5
  • 20

1 Answers1

0

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.

Stuart Lange
  • 4,049
  • 6
  • 24
  • 30
  • I'm not 100% on your explanation, I can't picture what is going on. Maybe I didn't explain myself properly. I'm not to bothered about separation but I reckon I should be really. What the intention is to have the SERVICES with their logic use the DATA/DATA ACCESS assembly to interact with the database. So if I understand you, I should put all mappings and nHibernate stuff in the DATA ACCESS assembly. No mappings should be present in SERVICES. Would that be correct? – Anthony Feb 29 '12 at 17:30
  • I thought to mention: Although my current project is not going to have plugins future ones may. In this case would the principal be the same; use the DATA ACCESS assembly to interact with the database? If so how would the mappings be managed then considering POCOs will not be present in the DATA ACCESS assembly for new tables if added? Sorry to be confusing the situation, I wish to start properly and go ahead the same instead of finding down the line I have to rewrite the lot. – Anthony Feb 29 '12 at 17:37
  • I just realized, if I expose the ISession through the DATA ACCESS assembly it won't matter where I write the POCOs will it. As long as the ISession/current session can be reached it essentially opens up the database. Although I reckon maybe this might be the way it should be done? – Anthony Feb 29 '12 at 17:47
  • I'm not quite clear on your use case. What do you mean by "how would the mappings be managed then considering POCOs will not be present in the DATA ACCESS assembly for new tables if added?" If you add a new table to the database, you will need to add a new POCO to your DATA assembly and a new mapping to your DATA ACCESS assembly. You obviously can't have your applications interact with new tables without code changes. – Stuart Lange Feb 29 '12 at 17:51
  • The problem here is it is very hard to discuss issues like this in a simple message back and forth. Do you know of any examples where the model you suggest is explained simply within a sample project, without extra baggage like Castle or SharpArchitecture. I learn by example and doing more so than reading. One that works with multiple service assemblies and is based arround nHibernate with Fluent? I have searched high and low but all examples are incomplete snippets or are missing the middle steps that are assumed known. – Anthony Feb 29 '12 at 18:36
  • There's not a good example that I know of. For further reading on ORM matters, I would direct you to ayende's blog : http://ayende.com/blog, which has many interesting posts on ORM (ayende is a big NHibernate contributor). As we've established, the standard design is to have one assembly that just contains your POCOs and has no persistence concerns, and another that handles "mapping" (your NHibernate mappings and perhaps some helper methods). – Stuart Lange Mar 01 '12 at 14:39