Layer Model Of Development


As a developer, the .NET framework and Visual Studio present many choices for choosing the right architecture, from placing the data access code directly in the UI through datasets and data source controls, to creating a data access layer that talks to the database, all the way to creating an architecture that consists of multiple layers, and use data-transfer objects to pass data back and forth.

What is a Layer?

A layer is a reusable portion of code that performs a specific function. In the .NET environment, a layer is usually setup as a project that represents this specific function. This specific layer is in charge of working with other layers to perform some specific goal. In an application where the presentation layer needs to extract information from a backend database, the presentation would utilize a series of layers to retrieve the data, rather than having the database calls embedded directly within itself.

Traditional Architecture

When the .NET 2.0 framework became available to the world, there were some neat features that allowed the developer to connect the framework's GUI controls directly to the database. This approach is very handy when rapidly developing applications. However, it's not always favorable to embed all of the business logic and data access code directly in the web site, for several reasons:

  • Putting all of the code in the web site (business logic and data access) can make the application harder to maintain and understand.
  • Reusing database queries in the presentation layer often isn't done, because of the typical data source control setup in the ASP.NET framework.
  • Relying on the data source controls can make debugging more difficult, often due to vague error messages.

So in looking for an alternative, we can separate the data access code and business logic into separate "layers", as shown in the following figure

Presentation Layer

The ASP.NET web site or windows forms application (the UI for the project) is called the presentation layer. The presentation layer is the most important layer simply because it's the one that everyone sees and uses. Even with a well structured business and data layer, if the presentation layer is designed poorly, this gives the users a poor view of the system.

It's best to remove as much business logic out of the UI and into the business layer. This usually involves more code, but in my mind, the excess time (which ranges from minimal to moderate, depending on the size of the application) pays off in the end.

Business Access Layer

Though a web site could talk to the data access layer directly, it usually goes through another layer called the business layer. The business layer is vital in that it validates the input conditions before calling a method from the data layer. This ensures the data input is correct before proceeding, and can often ensure that the outputs are correct as well. This validation of input is called business rules, meaning the rules that the business layer uses to make "judgments" about the data.

However, business rules don't only apply to data validation; these rules apply to any calculations or any other action that takes place in the business layer. Normally, it's best to put as much logic as possible in the business layer, which makes this logic reusable across applications.

Data Access Layer

The key component to most applications is the data. The data has to be served to the presentation layer somehow. The data layer is a separate component, whose sole purpose is to serve up the data from the database and return it to the caller. Through this approach, data can be logically reused, meaning that a portion of an application reusing the same query can make a call to one data layer method, instead of embedding the query multiple times. This is generally more maintainable.


We can develop very flexible system by following the architecture discuss above.

Similar Articles