3-tier architecture with ASP.NET Web Forms

Question

I have developed an ASP.NET Web Forms application in C#, consisting of:

1. .aspx and .Master pages containing all the web form UI controls
2. .aspx.cs pages for processing most of the business logic. I also have a Utility class in which I define many methods that are used by the different pages.
3. A SQL Server database to store the data.

When I Publish the application to the Production server, the .aspx.cs pages are removed, leaving only the .aspx pages. All the logic is compiled into a [ProjectName].dll file in the /bin folder.

Does this qualify as 3-tier architecture or is it still only 2-tier?

What steps should I take to convert this into 3-tier architecture? If I were to move all the methods in my .aspx.cs files to the Utility class, would that achieve a separation of business logic from the presentation tier?

Answer 1

A 3 tier architecture typically consists of a presentation layer, a business layer and a data layer.

The code behind files (aspx.cs) live in the presentation layer. In .net you should create seperate projects for each tier.

Check out this tutorial: http://www.c-sharpcorner.com/UploadFile/4d9083/create-and-implement-3-tier-architecture-in-Asp-Net/

Answer 2

The layers should be grouped by their responsibilities.

The project with the aspx files and the Utility can form a single layer as long as the Utility class contains code related to the WebForms issues like parsing a query string, working with the session. The code behind (aspx.cs and aspx.designer.cs) is compiled in a single dll. This is usually named Presentation or Application

There is no rule to have a single dll for a single layer.

For example you could have two dll's for your database layer. That means you will have in your solution two projects that contain the logic related to the database communication. One project might use ADO .Net only and the other project might use EntityFramework to persist and retrieve objects from the database. You usually find these projects classified as DataAccessLayer.

Until here you have a two tier structure: the Presentation layer and the DataAccess layer.

In the middle can be the Business layer. This can be another project that contains classes which orchestrate the objects that come from the Presentation and pass them to the DataAccess layer.

The coupling of these projects is another criteria used to classify the architectures. In a n-tier architecture the Presentation references Business and Business references DataAccess. This is also named the lasagna architecture, because a change in the bottom layer leads to changes in the upper ones. There are architectures where the DataAccess references Business to implement the interfaces needed by business related to the persistence concerns.

But don't get religious about these and all depends on the client needs. Often a one tier architecture is all what is needed.