Asp. NET three-tier architecture analysis

The BLL is the business logic layer

The DAL is the data access layer

Asp. NET three-tier architecture (DAL,BLL,UI)

The graph represents a three-layer structure. Where the web is the USL layer

Web–> bll–> Dal
|          | |
| V |
+–> Model <-+

One or three-tier architecture
1. Presentation layer (USL): The main means of the web, or can be expressed as WinForm mode. If the logical layer is quite powerful and complete, the logic layer can provide services perfectly, regardless of how the presentation layer is defined and changed.
2. Business Logic Layer (BLL): Mainly for the specific problem of operation, can also be understood as the operation of the data layer, the data business logic processing. If the data layer is a building block, the logical layer is the building blocks.
3. Data access Layer (DAL): Mainly for the original data (database or text files, such as the form of data storage) operations layer, rather than the original data, that is, the operation of the data, rather than the database, specifically the business logic layer or presentation layer

Provide data services.

Ii. Specific Distinctions
1. Presentation layer: The primary acceptance of the user's request, as well as the return of the data, provides the client with access to the application.
2. Business Logic Layer: mainly responsible for the operation of the data layer, that is, some data layer operations to combine.
3. Data Access layer: The main view of your data layer contains no logical processing, in fact, his various functions mainly to complete the operation of the data files, without the need to control other operations.

Iii. Summary
Three-layer structure is a strict hierarchical approach, that is, the data Access layer (DAL) can only be accessed by the Business Logic layer (BLL), the business logic layer can only be accessed by the presentation layer (USL), the user through the presentation layer of the request to the business logic layer, the business logic layer to complete the relevant business rules and logic, and access the database through the data access layer to get the data, and then return in reverse order to display the data in the presentation layer. Some three-storey structure also add factory, model and other layers, the actual is on the basis of the three layer of an extension and application.

A simple three-tier structure program typically includes the DAL BLL WEB model for several projects, and their reciprocal referential relationships are as follows
1) Web Reference Bll,model
2) BLL Reference Dal,model
3) DAL Reference Model
4) Model No references

A three-tier architecture is known as the presentation Layer (UI), the Business Logic layer (BLL), and the data Access Layer (DAL), and there are many ways to subdivide each layer. But the specific code how to write, in the end those files on which layer, but is vague. The following is a simple example to lead you to the actual three-tier architecture project, this example has only one function, is the user's simple management.

First create a blank solution, add the following items and files
1. Add an ASP. NET Web application project named UI, new Web form type file user.aspx (including User.aspx.cs)
2, add ClassLibrary project, named BLL, new class type file UserBLL.cs
3, add ClassLibrary project, named Dal, new class type file UserDAL.cs. Add a sqlhelper reference. (This is the Microsoft Data Access class, you can also write all the data access code directly.) I usually use my own data to access the class Dataaccesshelper).
4, add ClassLibrary project, named Model, new class type file UserModel.cs
5, add ClassLibrary project, named Idal, new interface type file IUserDAL.cs
6, add ClassLibrary project, named ClassFactory
I'm sure you can see that this is no different from the petshop example, and it's simpler, because the next is learning the three-tier architecture through PetShop. But some friends may be vague about the level of these projects and the relationship between them, and here's a description:
1, user.aspx and User.aspx.cs
These two files (and the items to which they belong, as well as below, are no longer repeated) are part of the presentation layer. User.aspx better understand, because it is the display page. User.aspx.cs Some people feel that they should not be counted, but to be drawn into the business logic layer. If not layered, then let User.aspx.cs to deal with business logic, and even the operation of the database is not a problem, but do layered, so it should not be. In a hierarchical structure, User.aspx.cs should only deal with display-related content, and no other part should be involved.
Example: We implement a list to display the user's function, then the work of extracting information is done by the BLL, the UI (in this case, User.aspx.cs) call the BLL to get UserInfo, the code is bound to the User.aspx data control, the display of the list is implemented. In this process, User.aspx.cs does not play a role in the UI, only to pass the data, and because most of the actual coding is so implemented, so that some people feel that User.aspx.cs should not be counted as UI, but should be integrated into the BLL responsible for logical processing. Continuing to look down, a new requirement was asked to add an icon to the front of each user, vividly showing the gender of the user, and a child icon under the age of 18. The realization of this demand, it is User.aspx.cs to do, in this case User.aspx.cs only to have a real purpose.
2, NewBLL.cs
Add the following methods:
Public IList getusers (): Returns a list of all user information
Public UserInfo GetUser (int UserId): Returns details for the specified user
public bool AddUser (UserInfo user): New user Information
public bool Changeuser (UserInfo user): Update users information
public void Removeuser (int UserId): Remove user information
This file belongs to the business logic layer and is designed to handle operations related to business logic. There may be a lot of people who think that the only use of this layer is to forward data from the presentation layer to the data layer. This is true, but this can only indicate that the project is relatively simple, or the relationship between the project itself and the business is not close (such as the current more popular mis), so the business layer has nothing to do, only played a forwarding role. But this does not mean that the business layer is dispensable, as the project grows, or the business relationship is more, the business layer will reflect its role.
The most likely error here is that the data manipulation code is drawn to the business logic layer, and the database is used as the data access layer.
For example: Some friends feel that the BLL layer is of little significance, but that the DAL data is forwarded to the UI without any processing. Take a look at this example
BLL Layer
Selectuser (UserInfo UserInfo) Gets the user details based on the incoming username or email.
Isexist (UserInfo UserInfo) determines whether the specified username or email is present.
Then the DAL also provides a method for the common BLL call
Selectuser (UserInfo UserInfo)
Isexist (UserInfo UserInfo)
In this way the BLL does only play a role in passing.
But if you do this:
Bll. Isexist (Userinfo Userinfo)
{
Uerinfo user = DAL. Selectuser (User);
Return (userinfo.id! = null);
}
Then the DAL does not have to implement the Isexist () method, and the BLL has logic-processing code.
3, UserModel.cs
Entity class, this thing, everyone may feel bad layering. including me before, it is understood that: Ui?àmodel?àbll?àmodel?àdal, so that the model in each layer has played a role of data transmission bridge. But here, we don't want to make things simple, but we want to be complicated.
What is model? It's nothing! It is optional in the three-tier architecture. It's actually the most basic thing in object-oriented programming: classes. A table is a class, a piece of news is also a class, int, string, Doublie, etc. is also a class, it is just a class.
In this way, the position of model in the three-tier architecture is the same as that of variables such as int,string, with no other purpose, only for storing data, except that it stores complex data. So if the objects in your project are very simple, it is possible to pass multiple parameters without model and make a three-tier architecture.
Then why do you have model, and what are the benefits of it? Here's what you think about a problem, plug it in here:
The model can play a big role in the transfer of the parameters of each layer.
When passing parameters between tiers, you can:
AddUser (Userid,username,userpassword, ...,)
You can also do this:
AddUser (UserInfo)
Both of these methods are good. At a glance, the second is certainly better.
When to pass parameters between layers using the common variable type (int,string,guid,double), what is the model pass? Here are a few ways:
Selectuser (int UserId)
Selectuserbyname (string username)
Selectuserbyname (string username,string password)
Selectuserbyemail (String email)
Selectuserbyemail (string email,string password)
Can be summed up as:
Selectuser (USERID)
Selectuser (user)
Here, the model object with the user contains four combinations of the three parameters of the Username,password,email. The UserID can also be incorporated into the user, but the other BLL in the project implements an interface with an ID parameter, so this is also preserved here.
Incoming userinfo, then how to deal with it, this needs to follow the order of the sequence, there is a specific code to decide.
This is the order in which this is handled
First see if you have username and password at the same time, then see if you have both email and password, then see if there is a username and see if there is an email. Processed in turn.
This way, if you add a new content later, the membership card (number), you do not have to change the interface, as long as the Dal in the code to increase the number of support on the line, and then the front desk to increase the membership card a content of the performance and processing.
4, UserDAL.cs
Public IList selectusers (): Returns a list of all user information
Public UserInfo selectuser (int UserId): Returns the trust information of the specified user
public bool Insertuser (UserInfo user): New user Information
public bool UpdateUser (UserInfo user): Update users information
public void DeleteUser (int UserId): Remove user information
Many people most noisy is the data access layer, in the end that part is the data access layer? Some think that the database is the data access layer, which is not clear about the definition, the DAL is the data access layer rather than the data storage layer, so the database cannot be this layer. Also some of the sqlhelper (or its similar components) as a data access layer, it is a dispensable thing, the role of sqlhelper is to reduce repetitive coding, improve coding efficiency, so if I am accustomed to care about efficiency or use a non-database data source, You can discard SqlHelper, a part that can be disposed of at will, and how can it be a layer in a three-tier architecture.
You can define this: code related to the operation of the data source should be placed in the data access layer and belong to the data access layer
5, Iuserdal
Data access layer interface, this is another dispensable thing, because petshop with it and ClassFactory class factory, so some projects regardless of need to support multi-data source, all of these two things to do in, and some do not even build classfactory and only built Idal, Then "iuserdal iuserdal = new Userdal ();", I don't know what it means. This is completely a tiger painting is not an anti-class dog.
Many people here have a misunderstanding, that is to think that there is such a relationship: Bll?àidal?àdal, think that Idal play a bridge between the BLL and the DAL, the BLL is through the idal to invoke the DAL. But the reality is that even if you encode it this way: "Iuserdal iuserdal = Classfacotry.createuserdal ();", the Userdal instance is actually executed when "iuserdal.selectusers ()" is executed. Instead of Iuserdal instances, the position of Idal in layer three is the relationship to the DAL level.
The above introduction basically illustrates the hierarchical structure of the three-tier architecture. In fact, I have a judge whether the three-tier architecture is a standard method, that is, the three layer of any layer completely replaced, will not affect the other two layers, the structure is basically in line with the three layer standard (although the implementation is more difficult ^_^). For example, if you change an item from B/S to C/s (or vice versa), the BLL and Dal do not have to be changed except the UI, or you can change SQL Server to Oracle, just replace Sqlserverdal to Oracledal, no additional operations, and so on. Originally wanted to add some specific code in the text, but the feeling is not very necessary, if you feel the need, I would like to add.
Summary: Do not think that a layer is useless to you, or that it is very simple to implement, that it is not necessary, or abandon it, or move it. As long as the layering, regardless of the layers, each layer should have a clear purpose and functional implementation, and not by the actual process, resulting in the same class of files in different layers of the situation occurs. Also do not appear on the same layer to achieve different functions of the situation occurs.

Note: This article is excerpt from, because feel write very good, very detailed, for beginners is very helpful, share to everyone to learn.

Asp. NET three-tier architecture analysis