Understanding Three‑Tier Architecture and Layered Design Patterns

When we first start learning architecture, we often think of layering; the classic three‑tier architecture consists of the presentation layer, the business layer, and the data‑access layer.

The presentation layer serves as the system's UI and UI‑logic. In ASP.NET WebForm, developers often place UI control handling code (reading, setting, events) in the page’s hidden code‑behind, relying on the business layer, and use data‑binding to reduce code.

Thus the presentation layer can be divided into UI view (responsible for data input/output display) and UI logic (handling data exchange between the UI view and the business layer while staying independent of UI technology).

UI view implementations include ASP.NET, WinForm, WPF, Silverlight, mobile web, smart devices, etc.

Two widely used patterns for separating UI view and UI logic are MVC and MVP.

MVC (Model‑View‑Controller) triggers actions from the view, calls a controller, which invokes the business layer, returns a model (domain model or DTO), and the view renders it.

MVP (Model‑View‑Presenter) fully separates view and model; the view defines an interface, and the presenter calls this interface to control the view, keeping both loosely coupled and independent of UI technology.

Another variant, the Presentation Model (PM), does not define an interface for the view; the model directly represents the view’s state and properties are bound to UI elements (e.g., WPF’s two‑way binding).

When a project grows and uses multiple UI technologies, a service layer is introduced between the presentation and business layers to decouple them. The service layer hides business details, communicates with the presentation layer via DTOs, and can be implemented with Web services, .NET Remoting, REST, or WCF (the author prefers WCF for its configurability).

The service layer improves reusability and cross‑platform communication but may add call overhead and affect performance.

The business layer implements core business processes, interacts with the data‑access layer, and contains domain models, DTO‑mapper layers, and middleware such as third‑party components or workflow engines.

Domain models define entity attributes, methods, and relationships; UML modeling is essential for mapping these models.

To convert DTOs to domain models, a DTO‑mapper layer is introduced.

Design patterns for business‑to‑data‑access interaction include Transaction Script, Table Module, Active Record, and Domain Model patterns, each with its own strengths and drawbacks.

Transaction Script uses procedural methods for each business flow, simple but prone to code duplication.

Table Module defines a business component per database table, often using DataSet in .NET, but can become unwieldy with many tables and complex relationships.

Active Record combines data and behavior in objects, suitable for simple domains but costly to maintain for complex business logic.

Domain Model, derived from Domain‑Driven Design, centers on business concepts and scales better for complex logic.

The data‑access layer provides persistence, handling reads, writes, transactions, and concurrency. It can be implemented via ORM frameworks or ADO.NET, and a repository interface layer with IoC containers (e.g., Unity, Spring.NET, Castle) can abstract different database implementations.

All layers may depend on a common infrastructure layer that includes utilities such as logging, exception handling, configuration, dependency injection, unit testing, and third‑party components (e.g., NHibernate, Spring.NET, Castle, Quartz).

Summary: Project type, scale, and business requirements shape system architecture; there is no single “best” architecture, only a better fit, and continuous reflection on extensibility is essential.