Onion Architecture

7,190 views
6,769 views

Published on

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,190
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
125
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • 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?
  • Onion Architecture

    1. 1. Matt Hidinger<br />Blog: http://matthidinger.com<br />Twitter: @MattHidinger<br />
    2. 2. Putting business value back to the core of our applications<br />Onion Architecture<br />
    3. 3. Traditional 3-layer Architecture<br />UI<br />Utilities / Common / Shared<br />ASP.NET<br />AutoMapper<br />Core / BLL<br />StructureMap<br />Inftrastructure / DAL<br />nHibernate /LINQ to SQL<br />Log4Net<br />DB<br />
    4. 4. Very easy for developers over time to put more and more business logic in the UI layer<br />Counter-productive to build your application on top of a specific technology that is sure to change over time<br />Logic is easily scattered all over, locating code becomes a major effort.<br />Developers over time struggle to determine where code should go… DAL? BLL? Utilities?<br />Business logic has many tentacles extending from it (directly and indirectly)<br />Library explosion: Makes it easy take a dependency without putting much thought into it, and now it’s littered all over the code base<br />Problems with Traditional Architecture<br />
    5. 5. Inverted Dependencies<br />UI<br />Utilities / Common / Shared<br />ASP.NET<br />Core / BLL<br />AutoMapper<br />Infrastructure / DAL<br />nHibernate /LINQ to SQL<br />StructureMap<br />Log4Net<br />DB<br />
    6. 6. Onion Architecture with Relative Sizes<br />ASP.NET<br />UI<br />Dependency Resolution (Utilities)<br />Core(BLL)<br />AutoMapper<br />StructureMap<br />nHibernate /LINQ to SQL<br />Infrastructure (DAL)<br />DB<br />Log4Net<br />
    7. 7. True loose coupling between layers/components<br />Limit re-write necessity over time, business value-adding logic is entirely self-contained<br />Application becomes very portable – next version of .NET or an entirely new language/platform<br />Business logic has no dependency tentacles (aside from your platform dependencies)<br />Architecture is more easily sustained over time, developers know exactly where components go, a lot of guesswork is removed<br />Infrastructure is free to use any data access library or external web services to do its work<br />UI and Data Access “layers” become much smaller, deal strictly with technology-related code<br />No more need for Common/Shared/Utilities project <br />Compiler enforces dependencies boundaries, impossible for Core to reference Infrastructure<br />Benefits of Onion Architecture<br />
    8. 8. ProductsControllerBrowser hits: /Products/List<br />IUserSession<br />User Interface<br />Application Services<br />HttpUserSession<<class>><br />Domain Services<br />IProductRepository<br />Dependency Resolution<br />ProductRepository<<class>><br />Domain Model<br />Application Core<br />DB<br />Infrastructure<br />
    9. 9.
    10. 10. Draw application/system using concentric circles, can only take dependency on something provided in an inner layer<br />Take ownership of your interfaces<br />Declare the API of the dependency (abstraction) in the inner layer, push implementation outward<br />Direction of dependency is toward the center<br />Externalize all technology related code<br />Push complexity as far outward as possible<br />Guiding Principles<br />User Interface<br />Application Services<br />Domain Services<br />Dependency Resolution<br />Domain Model<br />Application Core<br />DB<br />Infrastructure<br />
    11. 11. Show us some code already…<br />Demo!<br />

    ×