principled n-tier design
DESCRIPTION
Separating applications into separate layers or tiers has long been touted as an architectural best practice, but the typical naïve approach can result in tight coupling and a heavy dependence on the database. Alternative approaches to layered architectural design do not suffer from this limitation, allowing for loosely coupled, testable solutions that can swap alternative infrastructure implementations in and out of the application. In this session, we’ll examine the traditional N-Tier design and its deficiencies, and introduce an alternative based on the Ports and Adapters or Onion architectural pattern, and we’ll show how to set up a solution from scratch to take advantage of this approach. Learn more here: http://pluralsight.com/training/Courses/TableOfContents/n-tier-apps-part1TRANSCRIPT
Principled N-Tier Designor,
a Solution to the Solution Problem
Steve Smith@ardalis | ardalis.com
Telerik, Inc.
The Problem
Solution Level Pain
• Too Many Projects
• Too Few Projects
• Incorrect Abstraction
• The “Goldilocks” Solution– “Just right”
Relevant Principles
• Common Closure Principle• Common Reuse Principle• Stable Dependencies Principle• Stable Abstractions Principle• Separation of Concerns• Dependency Inversion Principle
Common Closure Principle
Classes that change together are packaged together.
Common Reuse Principle
Classes that are used together are packaged together.
Stable Dependencies Principle
Depend in the direction of stability.
Stable Abstractions Principle
Abstractness increases with stability.
Stability
Abst
ract
ness
Ideal
Rigid
Useless
More Principles
• Separation of ConcernsEstablish boundaries to separate behaviors and responsibilities within a system.
• Dependency InversionDepend on abstractions, not concrete implementations.
DEMOA Simple Guestbook Application
Testability
• Testability correlates with:– Loose coupling– Separation of Concerns– Maintainability
• You don’t have to have unit tests to have testable code!– Unit tests prove (or disprove) testability
DEMOAdding “Unit” Tests
SMTP4DEVhttp://smtp4dev.codeplex.com/
Incremental Improvement
• From a Single Project– Separate responsibilities using folders– Add Project(s)
• From Many Projects– Create a new Solution with only what you need– Spin off separate applications into own solutions
DEMOSeparation via Folders (still 1 project)
Problems
• Tests are still not unit tests– Tight coupling– Static Cling– Dependence on Data and Email Infrastructure concerns
• Nothing to prevent improper referencing of classes– e.g. UI code can call DAL code directly and bypass business
logic
• UI Content Folders mixed with Application Code Folders
Onion Architecture
• aka Ports and Adapters, • aka Hexagonal Architecture
• Core models and interfaces at center• Infrastructure and Implementation depends
on Core• UI depends on Core and has access to
Infrastructure
Onion Architecture
DEMOIntroduce Abstractions and Invert Dependencies (in folders)
Results
• Yay! Unit Tests that work!
• Boo! Still nothing to prevent improper referencing of classes– e.g. UI code can call DAL code directly and bypass
business logic
• Boo! Still mixing content and code folders
DEMORefactor into Projects
Results
• Testable Code• Separation of Concerns• Loose Coupling• Minimal logic in UI layer
A solid foundation for a maintainable application!
Automate
• One Click Build• One Click Test
DEMOSolution Automation – Build Scripts
DEMOMore Tests
References
• Separation of Concerns - http://bit.ly/zWujRe • Hexagonal Architecture - http://bit.ly/8Uxl5• Onion Architecture - http://bit.ly/4tWMT3• More Onion Architecture - http://bit.ly/NzF2Sz • New is Glue - http://bit.ly/Ijn98e
Pluralsight Resources• N-Tier Application Design in C# http://bit.ly/Msrwig • Design Patterns Library http://bit.ly/vyPEgK • SOLID Principles of OO Design http://bit.ly/OWF4la
Thanks!
• Find me at http://ardalis.com
• We’re hiring developers and trainers at Telerik!
• http://telerik.com/company/careers.aspx