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


2 Answers 2


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.

  • 1
    Is hiding "how the other layers operate internally" onion specific? From my point of view the important part of onion architecture is to hide dependencies to external services (database, email, internetaccess, ...) behind interfaces. The Interfaces are in the center of the onion, their implementation is in the outer "infrastructure layer", which hides the infrastructure specific code, like database-repositories.
    – k3b
    Commented Jun 19, 2013 at 15:46
  • That's true. :) So, should I limits internal abstractions or not?
    – dariol
    Commented Jun 19, 2013 at 17:14

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.

  • OK. Suppose I go that way, the onion arch way. Where and how to organize those stupid, simple queries for dictionaries like "Countries", etc.?
    – dariol
    Commented Jun 19, 2013 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.