3. Traditional 3-layer Architecture UI Utilities / Common / Shared ASP.NET AutoMapper Core / BLL StructureMap Inftrastructure / DAL nHibernate /LINQ to SQL Log4Net DB
4. Very easy for developers over time to put more and more business logic in the UI layer Counter-productive to build your application on top of a specific technology that is sure to change over time Logic is easily scattered all over, locating code becomes a major effort. Developers over time struggle to determine where code should go… DAL? BLL? Utilities? Business logic has many tentacles extending from it (directly and indirectly) Library explosion: Makes it easy take a dependency without putting much thought into it, and now it’s littered all over the code base Problems with Traditional Architecture
5. Inverted Dependencies UI Utilities / Common / Shared ASP.NET Core / BLL AutoMapper Infrastructure / DAL nHibernate /LINQ to SQL StructureMap Log4Net DB
6. Onion Architecture with Relative Sizes ASP.NET UI Dependency Resolution (Utilities) Core(BLL) AutoMapper StructureMap nHibernate /LINQ to SQL Infrastructure (DAL) DB Log4Net
7. True loose coupling between layers/components Limit re-write necessity over time, business value-adding logic is entirely self-contained Application becomes very portable – next version of .NET or an entirely new language/platform Business logic has no dependency tentacles (aside from your platform dependencies) Architecture is more easily sustained over time, developers know exactly where components go, a lot of guesswork is removed Infrastructure is free to use any data access library or external web services to do its work UI and Data Access “layers” become much smaller, deal strictly with technology-related code No more need for Common/Shared/Utilities project Compiler enforces dependencies boundaries, impossible for Core to reference Infrastructure Benefits of Onion Architecture
8. ProductsControllerBrowser hits: /Products/List IUserSession User Interface Application Services HttpUserSession<<class>> Domain Services IProductRepository Dependency Resolution ProductRepository<<class>> Domain Model Application Core DB Infrastructure
9.
10. Draw application/system using concentric circles, can only take dependency on something provided in an inner layer Take ownership of your interfaces Declare the API of the dependency (abstraction) in the inner layer, push implementation outward Direction of dependency is toward the center Externalize all technology related code Push complexity as far outward as possible Guiding Principles User Interface Application Services Domain Services Dependency Resolution Domain Model Application Core DB Infrastructure
The diagram only shows a database at the bottom, but there could be web services, XML files, etcWhy should we build our application on top of technology, which we know changes all the time?Transitive dependencies – if you depend on something, which depends on something else, you have a transitive dependency on that thingNot necessarily bad, or good, it just is
Business logic in the middle, depends on nothing. Promote business logic to the core of the application
BLL becomes core, holds ALL logic unique to the businessDAL becomes Infrastructure, responsible for technical implementation details onlyUtilities becomes Dependency ResolutionAll other layers become very thin
Should I create a factor for this or just new up my dependency?Where should the factory class go?Do I need to provide an interface for my component?Am I allowed to use classes out of this namespace?
