Onion Architecture

Question

I am setting up a project structure for an upcoming internal application trialling the Onion Architecture proposed by Palermo (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/).

I have followed his guidelines, however I need some verification on the structure of the project so far.

Before the diagrams, the questions:

1. I think the References are all correct (set up as per the diagram where an arrow means 'has a reference to') but some verification would be good.

2. What should I put in my dependency resolution layer? Is this where Helpers go? This has a reference to all other projects?

3. How do the web services & UI, communicate with the DAL? (Through the core? How?)

4. What should go where? [Broad question I know...]

The simplified conceptual diagram is as follows (Folders represent namespaces):

Woollyheaded

I think that putting the Interfaces inside of Infrastructure is wrong. It should be part of Core. – Uterine

Answer 1

I think the References are all correct (set up as per the diagram where an arrow means 'has a reference to') but some verification would be good.

1 It looks OK but I am not sure it's a good idea to insert dependency resolution into the diagram.

What should I put in my dependency resolution layer? Is this where Helpers go? This has a reference to all other projects?

2 I believe dependency injection stuff would be here.

How do the web services & UI, communicate with the DAL? (Through the core? How?)

3 It is core according to Palermo's diagram. In core, you will have repositories talking to DAL and domain models, and services (not web services) dealing with repositories and domain models. And UI/web services will mainly talk to services.

What should go where? [Broad question I know...]

4 Again, I think the answer is in Palermo's diagram. But in my opinion, organizing projects can be different and trivial when there is full understanding of the architecture.

Onion architecture became obvious to me once I understood DDD and necessary design patterns such as MVC, Dependency injection, Repository/Service, ORM.

Mullion

Answer 2

1. Yes they are, expect for the Dependency Resolution. These dependencies should be the other way around.
2. As the name (and the corrected references) implies it's purpose is to host some kind of IoC Container solution. It is no place for Helper classes, expect helper classes for resolution purposes.
3. The Core defines Interfaces for DAL or Domain Services. DAL and WebServices implements these interfaces. Inside the UI you would use the DAL or Service implementations through the defined interfaces. the correct implementation would be resolved through the help of the Dependency Resolution component (have a look at the concept of "Inversion Of Control" or "Dependency Injection").
4. As described in 3. the main thing is, that in Core you put the interfaces that will be implemented inside DAL and Web Services. And in Core you would implement your real business model. this model can make use of the DAL and the Web Services via the defined interfaces (with the help of the Dependency Resolution component).

Protractor

Are you sure about dependency resolution? If so, wouldn't that mean that the dependency would be on the inside of the onion, rather than the outside? And this would mean that the Core depended on the dependency resolution assembly - which doesn;t seem right? – Woollyheaded

Right, the core should have no dependency to DR. But the others need DR to get implementations of Core interfaces: example in UI: { DR.Resolve<ISomeService>().CallserviceMethod(); } – Protractor

I don't agree about dependency resolution, rObiwahn. DR should be on the outer layer and reference the inner layers. By saying DR.Resolve(ISomeService) it sounds like service locator anti-pattern. Dependency Resolution needs to know where all of the implementations are so that it can resolve them when it needs to. – Soundproof