0

This is my first try at implementing the Onion Architecture.

enter image description here

AppService -> folder for the abstractions for the entire Application
Business -> Business logic using the abstractions in the Core project
DataService -> folder for abstractions that are implemented in the DataAccess project
Model -> Entities used by the application
WebService -> folder for abstractions that are implemented in the WebAccess project
  1. Are the folder above placed correct?
  2. Is the place for the DependencyResolution project in the Domain folder?
  3. Should each of the projects in the Infrastructure contain a DependencyRegistrar file that registers the interfaces in the Core project with the implementation in the project it's included in?
  4. Should the WebApi project be placed in Presentation->Api? Is it a presentation?
  5. Should I place all unit tests for each project in the 'Tests' folder?

Thanks in advance.

Ivan Prodanov
  • 34,634
  • 78
  • 176
  • 248

1 Answers1

1
  1. Your folder structure generally seems fine. Personally, I go for a more modular approach where folders in your core project are actually individual projects in mine, but this is just my preference.
  2. Dependency Resolution isn't part of your domain and it isn't really infrastructure either (at least in my opinion). It's a concept in and of itself.
  3. The DependencyRegistrars seem unnecessary. It's the responsibility of Dependency Resolution to map abstractions to implementations.
  4. My immediate reaction would be no, but in the past I have done single page applications where I have used MVC and WebApi in the same project. Thus together they would make the client. If each mobile client has its own backend, I would put those projects in the same folder as the client. Otherwise, I would consider a top-level "backend" or "services" solution folder to put them in if they are shared between multiple different clients.
  5. I think it makes more sense for each project and their tests to live next to each other so navigating from one to the other or vice-versa is easy (i.e. not having to scroll up and down the solution).

So apart from Dependency Resolution living in Domain and the DependencyRegistrars, it seems fine. The specifics are down to what you think is best.

George Howarth
  • 2,767
  • 20
  • 18
  • All diagrams of Onion show Dependency Resolution as the outmost layer so UI cannot depend on DR. Does your UI depend on DR? How do you solve that? – Ivan Prodanov Apr 30 '14 at 09:21
  • Basically, the way I have designed my applications is that each [Composition Root](http://blog.ploeh.dk/2011/07/28/CompositionRoot/) should have its own bootstrapper, which in turn references DR (much like how it's described in [this question](http://stackoverflow.com/questions/14891371/dependency-resolution-in-onion-architecture)). Perhaps my understanding of DR is slightly off from what it should be, but it's worked well for me personally whilst remaining compatible with the core philosophy of the architecture which is to externalize dependencies. – George Howarth Apr 30 '14 at 10:23
  • Thanks, I accepted your answer. But I can't accomplish this with WebActivator. One of my UI is a WPF application and I don't know how it is possible to externalize the DR in such case without referencing it directly in the WPF app. Can you give me a clue? – Ivan Prodanov May 01 '14 at 09:25
  • 1
    So what you would do is have UI reference a bootstrapper project which in turn references DR (UI > Bootstrapper > DR). It's exactly the same as you would do with a `HttpApplication` (Web Client > Bootstrapper > DR). All WebActivator does is hookup a method to a specific point in the application's lifecyle. – George Howarth May 01 '14 at 10:54