The N-Tier Pattern
Microsoft has been committed to n-tier development for a very long time. It was the heart of the now-deprecated Distributed interNet Architecture (DNA) introduced in 1999, and it remains the heart of .NET today.
As noted earlier, n-tier really means "three or more" tiers. The "required" three are the presentation (user interface), business logic, and persistence (data) layers (see Figure 8-1).
It is possible, of course, to have many more than three tiers. For example, some developers find it useful to break up the application layer into a workflow and a rules layer, and to break up the persistence layer into a data layer that exists in the application and a data layer that is implemented in stored procedures and thus exists on the database server. Such an architecture is illustrated in Figure 8-2.
The key to solid n-tier development is clean separation between the layers. The presentation-layer objects should know as little as possible about the internals of the business objects, and they certainly should know nothing about how the data they represent is persisted.
The arguments for this decoupling between the layers only grow stronger as we face a rapidly changing and evolving development environment. The presentation options are proliferating more quickly than we can learn how to code for them, and the kinds of data (and the volume of data) that we must present are expanding exponentially.
Figure 8-1. Typical three-tier architecture
We are no longer in the position ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access