Skip to content

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

software development, coding, pluralsight4 min read

ntier1 pluralsight

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)


  • 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.