Notes from Creating N-Tier Applications in C#, Part 1 Pluralsight Course

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

• Problems this design can help with:
  • no easy way to test notification business logic
  • duplicated and/or tightly coupled logic
  • changes to one portion of a system requiring changes to another portion
• Refactoring to N-tier design:
  • Identify your layers
  • Push your code from the original file into these layers
• This module is mostly demos

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

• N-Tier Design = logical and physical separation of responsibilities within an application
• Layers = logical separation for maintainability
• Tiers = physical separation for scalability, security, fault tolerance, etc.
• Applications can evolve over time
• Avoid end runs around layers of your design
• Duplication can be eliminated via refactoring to N-tier design
• Concerns should be separated between layers
• Layers should communicate with one another via well-defined, cohesive interfaces
• domain-centric design focuses on your application's domain logic
• dependency injection can be used to put application logic at the center of the dependencies
  • used well with strategy pattern
• domain-centric design leads to easier testing
• much easier to start with domain-centric design than to refactor to it later
• here are my notes from Creating N-Tier Applications in C#, Part 2.

Thanks for reading! I hope you find this and other articles here at ilyanaDev helpful! Be sure to follow me on Twitter @ilyanaDev.