11

I see only benefits to the onion architecture over the 3 layered architecture where the BL had responsibility to call methods on DAL (or an interface of DAL) to do CRUD. The onion has better separation of concerns, testability, maintainability and is cleaner.

So is the onion architecture indeed better in all aspects and 3 layered architecture is just an old way of doing things, or there are some scenarios where I should prefer to use the 3 layered architecture, if so - which?

  • Better anonymity could be an advantage. :P – CodesInChaos May 29 '16 at 15:30
  • I wonder why so many ppl strives itself to compare these things in terms of better/worse instead of terms of adequacy – Laiv May 29 '16 at 16:12
  • @CodesInChaos - Could you please explain what you mean I didn't quite get it? – BornToCode May 29 '16 at 19:19
  • How exactly the Onion architecture has "better separation of concerns", since said separation is achieved by simply having well-defined layers? Also, I don't see any inherent advantage in testability. – Rogério yesterday
10

Layers, Onions, Ports, Adapters: it's all the same

Since this article makes clear that onion is equivalent to 3 layer + application of the Dependency Inversion Principle (DIP), then the question becomes "where should I prefer to use DIP?" I'd say any non-toy project. Using DIP allows the core of your code to be more isolated, testable and maintainable. When you really don't care about that is when it's a throw-away project or when you are trading maintainability for performance.

Also, don't confuse DIP with DI (Dependency Injection) containers. One doesn't imply the other.

  • In my experience (with large and complex business apps), DIP is mostly useless. Remember, the goal of applying DIP to a given component A that uses another component B is so you can reuse A with a different implementation for B (with A and B being in separate layers). However, such an "A" component, most often than not, never gets reused in a different app, so there is no point to it... – Rogério yesterday
  • The argument made by the referenced article, that layered architecture is bad because "it violates the Dependency Inversion Principle" is a falacy. DIP is not a widely applicable principle of software design, but merely a technique that you may choose to apply to a given component, on a component by component basis, and only if you want to more easily reuse the component in a different context/application. This "principle" shouldn't be called a principle at all - it's not something like SRP (Single Responsibilty Principle) or LSP (Liskov Substitution Principle), which are true principles. – Rogério yesterday
  • @Rogério This is a strange argument to make. For one thing, Dependency Inversion is one of the SOLID principles right along side SRP and LSP. I have a hard time wanting to imagine large and complex business apps with the same magic strings (db connect strings, url endpoints, etc) copied all over the place. You do realize that configuration is a kind of dependency, right? If you were talking about DI frameworks, then I would have to agree with your sentiment -- I never use those. – Kasey Speakman yesterday
  • Yes, I am aware of SOLID. To me, OCP, ISP, and DIP are not true principles, but "mere" guidelines that you choose to apply or not in a given situation, based on your design goals. Having "magic strings copied all over the place" has no relation to SOLID, what are you talking about? Perhaps you should actually read up on what "SOLID" is? (I have.) And configuration is not a kind a dependency, it's something that "configures" certain dependencies. BTW, none of the SOLID "principles" makes any mention of configuration (nor of DI, which is not a part of SOLID). – Rogério 14 hours ago
  • @Rogério Literally, the D in SOLID is Dependency Inversion Principle. So, I don't think there is enough common understanding between us of what a dependency is for me to continue to respond to your comments. Good luck! – Kasey Speakman 13 hours ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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