I’m fan of onion architecture but looking for some relaxing solutions in some areas.
First of all I was thinking about communicating directly from UI (from controller in mvc) to data on the read side. As everyone can see UI should not be referenced to any assembly except Core.
When I want to display list of countries on page to select one, that I really need to do this through my Core?
I see two solutions:
- UI has reference to NHibernate and talks directly
- add a very thin abstraction layer where I define IFinder<> (only to read data) which will be implemented in infrastructure
Thoughts?
The purpose of an onion architecture is that one layer doesn’t need to be concerned with how the other layers operate internally.
The fact that the model uses Hibernate to get the list of countries is something the UI layer doesn’t need to know. You could, for example later decide to hardcode the list of countries, cache it in memory or try out some exotic NoSQL solution which isn’t supported by Hibernate. This is a decision which should only concern the model, not the UI. So the UI should obtain all information about the model through encapsulating method calls, no matter how thin they are initially.
2
If you directly call NHibernate from the UI layer you are not implementing the Onion architecture, and your code will be highly coupled. For a small project this may not matter, but if you’re creating something more lasting or an enterprise solution you will want to create an interface as in your second example to ensure that you have full flexibility to change the concrete implementation later on. You will also most likely want to look into using an IoC container to inject your dependencies, though again consider whether your project really needs the Onion approach as all this will add a fairly significant coding overhead.
1