principled n-tier design

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