Downloaded 218 times
More Related Content
Similar to Onion Architecture
Onion Architecture
- 1. Matt HidingerBlog: http://matthidinger.comTwitter: @MattHidinger
- 2. Putting business valueback to the core of our applicationsOnion Architecture
- 3. Traditional 3-layer ArchitectureUIUtilities/ Common / SharedASP.NETAutoMapperCore / BLLStructureMapInftrastructure / DALnHibernate /LINQ to SQLLog4NetDB
- 4. Very easy fordevelopers over time to put more and more business logic in the UI layerCounter-productive to build your application on top of a specific technology that is sure to change over timeLogic 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 baseProblems with Traditional Architecture
- 5. Inverted DependenciesUIUtilities /Common / SharedASP.NETCore / BLLAutoMapperInfrastructure / DALnHibernate /LINQ to SQLStructureMapLog4NetDB
- 6. Onion Architecture withRelative SizesASP.NETUIDependency Resolution (Utilities)Core(BLL)AutoMapperStructureMapnHibernate /LINQ to SQLInfrastructure (DAL)DBLog4Net
- 7. True loose couplingbetween layers/componentsLimit re-write necessity over time, business value-adding logic is entirely self-containedApplication becomes very portable – next version of .NET or an entirely new language/platformBusiness 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 removedInfrastructure is free to use any data access library or external web services to do its workUI and Data Access “layers” become much smaller, deal strictly with technology-related codeNo more need for Common/Shared/Utilities project Compiler enforces dependencies boundaries, impossible for Core to reference InfrastructureBenefits of Onion Architecture
- 8. ProductsControllerBrowser hits: /Products/ListIUserSessionUserInterfaceApplication ServicesHttpUserSession<<class>>Domain ServicesIProductRepositoryDependency ResolutionProductRepository<<class>>Domain ModelApplication CoreDBInfrastructure
- 10. Draw application/system usingconcentric circles, can only take dependency on something provided in an inner layerTake ownership of your interfacesDeclare the API of the dependency (abstraction) in the inner layer, push implementation outwardDirection of dependency is toward the centerExternalize all technology related codePush complexity as far outward as possibleGuiding PrinciplesUser InterfaceApplication ServicesDomain ServicesDependency ResolutionDomain ModelApplication CoreDBInfrastructure
- 11. Show us somecode already…Demo!
Editor's Notes
- #4 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
- #6 Business logic in the middle, depends on nothing. Promote business logic to the core of the application
- #7 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
- #8 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?