Three Tier Model

If the project is large, with a lot of complicated business logic, then it's more useful to separate the BL and DAL into in their own assemblies so that we can change the BL code without changing the DAL assembly. This makes our application more flexible and loosely-coupled as we can use a different DAL assembly for a different database with the same BL assembly.

The solution will have:

  • ASP.NET Web Project having Presentation Layer coding in ASPX and ASCX files, under namespace MyApp.Web (Tier 1)
  • A class library project having business logic code, with namespace, MyApp.Code.Business (Tier 2)
  • A class library project DAL for data access code, with namespace, MyApp.Code.DAL (Tier 3)

Note

Once again, if we also bring the Presentation and Database to be a part of the entire application here, the above 3-tier model would become a 5-tier model!

The above structures and layouts show some of the possible ways we can architect our solutions, and also illustrate the differences between layers and tiers. We can have more tiers (n-tier), and can customize our solution with a mix of tiers and layers, according to the project's needs. There is a common misconception among beginner developers that a 3-tier (or n-tier) architecture is the only best model, and many new developers try to blindly follow this model without even giving a second thought to their actual project's needs. As we go from one tier to n-tier, the code complexity increases, and it is better not to go for an n-tier architecture unless the application demands it. For small projects, we can keep things simple and easy.

In the coming chapters we will learn how, why, and which architecture to use (with sample projects), depending on the business needs.

上一章目录下一章