Onion Architecture
Upcoming SlideShare
Loading in...5
×
 

Onion Architecture

on

  • 5,433 views

 

Statistics

Views

Total Views
5,433
Views on SlideShare
3,948
Embed Views
1,485

Actions

Likes
2
Downloads
68
Comments
0

3 Embeds 1,485

http://www.matthidinger.com 1483
http://www.google.com 1
http://matthidinger.azurewebsites.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Onion Architecture Presentation Transcript

  • Matt Hidinger
    Blog: http://matthidinger.com
    Twitter: @MattHidinger
  • Putting business value back to the core of our applications
    Onion Architecture
  • Traditional 3-layer Architecture
    UI
    Utilities / Common / Shared
    ASP.NET
    AutoMapper
    Core / BLL
    StructureMap
    Inftrastructure / DAL
    nHibernate /LINQ to SQL
    Log4Net
    DB
  • 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
  • Inverted Dependencies
    UI
    Utilities / Common / Shared
    ASP.NET
    Core / BLL
    AutoMapper
    Infrastructure / DAL
    nHibernate /LINQ to SQL
    StructureMap
    Log4Net
    DB
  • Onion Architecture with Relative Sizes
    ASP.NET
    UI
    Dependency Resolution (Utilities)
    Core(BLL)
    AutoMapper
    StructureMap
    nHibernate /LINQ to SQL
    Infrastructure (DAL)
    DB
    Log4Net
  • 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
  • ProductsControllerBrowser hits: /Products/List
    IUserSession
    User Interface
    Application Services
    HttpUserSession<<class>>
    Domain Services
    IProductRepository
    Dependency Resolution
    ProductRepository<<class>>
    Domain Model
    Application Core
    DB
    Infrastructure
  • 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
  • Show us some code already…
    Demo!