Layered Design Pattern for Enterprise Applications

In this post, I'll briefly describe how I've been layering applications lately. I wanted to capture the concepts and provide some explanations. I do not pretend to think this is the only way to design applications, but I do think it is a good way. It is also fairly typical.


I'll start with the most basic of designs:

Data Access - this layer in my mind if very granular. The classes involved have the single mission to read and write data to the database. There may be a one to one relationship between data access classes and database tables, but not always. There are some cases when it is prudent to denormalize data.

Service - the service layer maps to application functionality from a logical perspective. Take the functionality of your application and partition it into logical modules and you have a basis for services. Thus, service classes are more coarse than data access classes, but you may have multiple services depending on the complexity of the application.

Presentation - the presentation layer provides the business functionality behind the user interfaces. Here is where the interactions between the user and the services are orchestrated. I typcially will have a one to one relationship between Presenters and UIs (views), although sometimes a UI may have a composition of complex user controls that each have their own presenter.

User Interface - this layer depends on the platform (web, windows, modile, etc.) I want this layer to be as simple as possible and contain no business logic. It can get complicated, though, as more and more advanced controls are introduced.


Depending on how you are implementing an application, you might have additional layers. For instance, in a client server environment, there is the need for a web service and proxy layer:

You also might need a layer to sit on top of the UI and Presenter layers. This layer (e.g. Application Controller) would orchestrate the interaction between the User Interfaces and it would interact with the Presenters (assuming an MVP pattern):

Organizing a Solution

Thus far what I've laid out is straightforward and fairly ubiquitous. Now I want to layout some details about how all this fits together in a .NET Solution.

It is reasonable to think that each layer would have its own assembly, or set of assemblies. While that is perfectly fine, There is a little more complexity than that. For example, each class in each layer will likely have an interface. Although those interfaces can coexist with the classes that implement them, I find it makes more sense to separate them. I do not, however, see the need to have a separate assembly for interfaces at each layer. Instead, I prefer a single assembly to contain interfaces. This assembly then becomes something of a definition for the application.

Some may prefer to break this definition assembly into two separate assemblies, one for data access interfaces and another for the other interfaces. This would be meaningful in a client server application where the client hardly needs any knowledge of the data access layer (in truth, it would not need the service layer, either, but the service interfaces are used to define the web service proxies, so they are needed.)

There are other classes that cannot be relagated to a specific layer that will also need assemblies. Domain objects or data access objects for one, but also any framework classes you may require (your framework, not .NET's.) With these considerations, there are at least 6 assemblies needed:

1. Framework and Domain
2. Definitions
3. Data Access
4. Service
5. Presentation
6. Client

I actually like separating Framework classes and Domain classes. When using Entity Framework, it may also be useful to separate the database context and entity classes (assuming they are different from the domain classes) into their own assembly - but that's a topic for another post.

To put a little more meat on these thoughts, here's how I would organize projects in a solution for application X:

• X.Framework
• X.Domain
• X.Definition
• X.DataAccess
• X.Service
• X.Presentation
• X.Client (a Web App, perhaps?)

If I were using Entity Framework, it would be:

• X.Framework
• X.Domain
• X.Definition
• X.EntityFramework
• X.DataAccess
• X.Service
• X.Presentation
• X.Client 

If I needed a client server application, it would be:

• X.Framework
• X.Domain
• X.Definition
• X.EntityFramework
• X.DataAccess
• X.Service
• X.WebService
• X.WebServiceProxy
• X.Presentation
• X.Client