Designing a Stable Architecture for .NET Applications: Presentation, Business, and Data Layers

We often develop seemingly different applications, but the underlying architecture remains relatively stable; a good architecture makes programming enjoyable and keeps software healthy, while poor design harms developers and shortens the system’s lifecycle. This article offers a brief discussion of a typical architectural flow for applications built on the Microsoft .NET platform.

Overall Design Diagram

Presentation Layer

The presentation layer consists of the UI (User Interface) and UI control logic.

UI (User Interface)

The UI is the client‑side interface that receives commands, requests, and data from the user, forwards them to the business layer, and displays the results. Applications are generally divided into BS (Browser‑Server) and CS (Client‑Server) structures. BS requires only server maintenance, while CS offers richer interaction. RIA (Rich Internet Application) combines both advantages, relying on a client‑side interpreter such as Microsoft SmartClient, Avalon, Macromedia Flex, Bindows, Ajax, etc.

UI Control Logic

UI control logic handles data exchange between the UI and business layer, manages UI state flows, and performs simple validation and formatting. In .NET’s event‑driven model, this logic resides in event handlers (e.g., PageLoad, ButtonClick). Large volumes of data exchange and complex state management can bloat these handlers, so encapsulation is essential.

1. Data exchange between UI and business entities

Data Transfer Objects (DTOs) carry data between UI controls and the business layer. Automatic mapping can be achieved with an Adapter that follows naming conventions between UI controls and DTO properties, eliminating the need for configuration files.

2. State and flow management

Business logic should not be tangled with the presentation layer. The MVC (Model‑View‑Controller) pattern provides a solution: the Controller acts as a flow manager, dispatching commands and data from the UI to the business layer or other UI components, allowing separate configuration of permissions and processes. .NET MVC options include Microsoft’s UIPAB, open‑source Mavrick.NET, and Lattis.

Business Layer

The business layer encapsulates core logic such as validation, transaction handling, and permission checks. It is divided into business data and business operations.

Business Data

Business data, acting as DTOs, can be modeled as either Table Model or Domain Model. Table Model maps database tables directly to objects, suitable for simple, fast development but less expressive for complex relationships. Domain Model uses OO concepts to represent business concepts, offering better performance and clarity at the cost of custom serialization.

Considering reusability, extensibility, and performance, Domain Model is generally preferred for complex systems.

Business Operations

Business operations manipulate business data (validation, flow, integration, transactions, permissions) without directly accessing data sources. Two design approaches exist: separating data objects (DTOs) from service classes, or combining data and related operations into a single business entity. The latter aligns with a rich Domain Model and promotes component reuse.

Inter‑module Dependencies

Managing reusable components (e.g., permission management, email sending) is essential. IoC containers provide injection of modules without the caller knowing their concrete implementations; however, mature .NET options are limited, with Spring.NET being the primary choice.

Business Data Access Layer

This layer offers a minimal set of interfaces for the business layer to interact with data sources, shielding the business logic from storage details. It consists of a DAO (Data Access Object) layer and a system service layer, both residing at the same architectural level.

Relationship Diagram of Business Layer and Business Data Access Layer

Data Layer

The data layer provides an abstract interface to data sources, allowing interchangeable DataProviders. Three common approaches are:

1. ADO.NET Wrapper

Low‑level wrappers around ADO.NET offer high performance and fine‑grained SQL control but require manual parameter handling and lack declarative transaction support. Examples include Microsoft’s Enterprise Library DAAB and its predecessors.

2. ORM Components

Object‑Relational Mapping abstracts database interactions, simplifying development and maintenance. Drawbacks include limited optimization for specific databases and performance overhead. .NET ORM options include NHibernate, Gentle.NET, XPO, Grove.NET, among others, many of which are still in beta or commercial.

3. DataMapper (SqlMapper)

DataMapper combines ORM convenience with the ability to write custom SQL for optimization. iBatis.NET is a mature open‑source implementation that allows swapping DAOs without recompilation.

In summary, .NET offers fewer mature architectural components compared to Java, but the platform is evolving. The presented architecture reflects personal understanding and is not a one‑size‑fits‑all solution; adjustments are required for specific environments. Feedback is welcome, and the article will be updated as technologies advance.