Notes from Creating N-Tier Applications in C#, Part 1 Pluralsight Course
Date Published: July 16, 2020

Steve Smith's Pluralsight course Creating N-Tier Applications in C#, Part 1 does a great job of explaining the basics of N-Tier applications.
I recently completed Creating N-Tier Applications in C#, Part 1 by Steve Smith. Here are my notes:
Application Evolution
-
N Tier refers to a system composed of some n number of layers
- Most commonly 3 - UI, Business Logic, Data Access Logic
- Separated tiers are logically separated. Sometimes also physically separated. Sometimes separate deployment and even separate development
-
"Tier" and "Layer" more or less interchangeable
- "Layer" can be applied specifically to logical structure of application
- "Tier" can be applied specifically to the physical structure of the system
-
Logical separation:
- code organization
- namespaces, classes, folders, assemblies, etc.
- a software design pattern
-
Physical separation:
- infrastructure organization
- separate physical processes, machines, devices
- a software architecture
- generally impossible without logical separation
-
Benefits:
- improved productivity via reuse
- improved productivity via team segmentation
- improved maintainability
- looser coupling
- more physical deployment options
-
Drawbacks and Risks:
- reduced performance, esp. when physically separated
- more complex design
- more complex deployment
-
Coupling:
- loose coupling allows connected modules to change independently of one another
- tight coupling describes when changes in one module require changes in others
- avoid this
- Follow principles of object-oriented design to facilitate loose coupling
-
End runs - when one application layer calls to another that is not directly below it
- avoid this!
- and avoid allowing concerns from one layer to leak up to a higher layer - information hiding!
- end runs -> no advantage gained from n-tier design (but lots of disadvantage)
-
Monolithic application
- n-tier where n = 1
- no logical or physical separation of concerns
- all parts of the application are included
Data-Centric N-Tier Design
Domain-Centric N-Tier Design
-
Domain-Centric Design
- focused on domain
- problem-space of application = domain
- objects you design to model domain = domain objects = model objects
- should describe problem domain, include any required business logic
- do not depend on external infrastructure
-
Refactor to invert dependencies from a data-centric N-tier design:
- create projects for core and infrastrucutre
- move BLL methods to core or infrastructure services
- create interfaces for dependencies and provide them to classes via constructors
- push object graph creation to UI layer
- Onion architecture = ports and adapters architecture = hexagonal architecture
-
Onion architecture principles:
- all code depends on layers closer to center
- domain model at center
- inner layers define interfaces, outer layers implement those interfaces - abstraction!
- layered behavior around the domain model
- infrastructure and UI concerns pushed to end
- depend on Application Core, not vice versa
- Repository pattern used for infrastructure concerns related to persistence
-
Domain-Centric design from scratch:
- create a blank solution
- add a core class library project
- add an infrastructure class library project
- add your UI project
- add references to core from infrastructure and UI
- add reference to infrastructure from UI (if needed)
Summary
Thanks for reading! I hope you find this and other articles here at ilyanaDev helpful! Be sure to follow me on Twitter @ilyanaDev.