BLL is the Business Logic Layer
DAL is Data Access Layer
Three-tier architecture of ASP.NET (DAL, BLL, UI)
Graphics represent a three-layer structure. The web is the USL layer
web –> bll –> dal
| | |
| V |
+–> model <—+
1. Three-tier architecture
1. Presentation layer (USL): It mainly represents the WEB method, but can also be expressed as WINFORM mode. If the logic layer is quite robust and well-established, it will serve perfectly no matter how the performance layer is defined and changed.
2. Business logic layer (BLL): mainly for specific problems, it can also be understood as the operation of the data layer and the logical processing of data business. If the data layer is the building blocks, then the logic layer is the building block.
3. Data access layer (DAL): It is mainly the operation layer of the original data (in the form of a database or text file or other form of storing data), rather than the original data, that is, the operation of the data, not the database, specifically the business logic layer or the presentation layer
Provision of data services.
2. Specific distinction
1. Presentation layer: mainly accepts the user's request, and returns data, providing the client with access to the application.
2. Business logic layer: mainly responsible for the operation of the data layer, that is, the combination of some data layer operations.
3. Data access layer: It mainly depends on whether your data layer contains logical processing, in fact, its functions mainly complete various operations on the data file, and do not have to worry about other operations.
3. Summary
The 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), and the business logic layer can only be accessed by the presentation layer (USL). Some three-layer structures also add other layers such as Factory and Model, which are actually an extension and application on the basis of these three layers.
A simple three-layer program generally includes several projects of the DAL BLL WEB Model, and their mutual references are as follows
1) WEB references BLL, Model
2) BLL references DAL, Model
3) DAL references Model
4) Model has no citations
When it comes to the three-tier architecture, everyone knows that it is the performance layer (UI), the business logic layer (BLL) and the data access layer (DAL), and there are many ways to subdivide each layer. But how to write the specific code and which layer those files are counted in is vague. The following is a simple example to lead you to practice a three-layer architecture project, this example has only one function, that is, simple management of users.
First, create a blank solution and add the following items and files
1. Add a ASP.NET Web Application project, name it UI, and create a new Web Form file User.aspx (including User.aspx.cs)
2. Add a ClassLibrary project, name it BLL, and create a new Class file UserBLL.cs
3. Add a ClassLibrary project, name it DAL, and create a new Class file UserDAL.cs. Add a SQLHelper reference. (This is Microsoft's data access class, or you can write all the data access code directly.) I usually use the DataAccessHelper class that I write).
4. Add a ClassLibrary project, name it Model, and create a new Class type file UserModel.cs
5. Add a ClassLibrary project, name it IDAL, and create a new Interface file IUserDAL.cs
6. Add a ClassLibrary project and name it ClassFactory
I believe you have seen that this is no different from Petshop's example, and it is simpler, because I also learn the three-layer architecture through Petshop. However, some friends may be vague about the level of these projects and the relationship between them, here is an explanation of them one by one:
1. User.aspx and User.aspx.cs
Both documents (and the items to which the file belongs, as well as below, will not be repeated) are part of the presentation layer. User.aspx is easier to understand because it is a display page. User.aspx.cs some people think that it should not be counted, but should be included in the business logic layer. If you don't do layering, then there is no problem in letting User.aspx.cs handle business logic and even operate the database, but if you do layering, this should not be done. In a hierarchical structure, User.aspx.cs should only deal with content related to display, and nothing else should be covered.
For example, if we implement the function of displaying users in the form of a list, then the work of extracting information is done by BLL, and after the UI (in this case, it is User.aspx.cs) calls BLL to get UserInfo, it is bound to the data control of the User.aspx through code to realize the display of the list. In this process User.aspx.cs it does not play a role in the UI, it is only used to pass data, and because most of the actual coding is implemented like this, some people feel that User.aspx.cs should not be counted as UI, but should be merged into BLL for logical processing. Looking further, a new requirement was put forward to add an icon in front of each user to vividly represent the user's gender, and for those under 18 years old, it was represented by a child icon. The realization of this requirement is the turn of User.aspx.cs, and in this case User.aspx.cs it has a real use.
2、NewBLL.cs
Add the following methods:
public IList GetUsers(): Returns a list of all user information
public UserInfo GetUser(int UserId): Returns the details of the specified user
public bool AddUser(UserInfo User): Added user information
public bool ChangeUser(UserInfo User): Updates user information
public void RemoveUser(int UserId): Removes user information
This file belongs to the business logic layer and is dedicated to handling operations related to business logic. Many people may think that the only use of this layer is to forward the data from the performance layer to the data layer. There are indeed many such cases, but this can only mean that the project is relatively simple, or the relationship between the project itself and the business is not closely integrated (such as the current popular MIS), so the business layer has nothing to do, and only plays a forwarding role. But this does not mean that the business layer is dispensable, as the project increases, or there are more business relationships, the business layer will reflect its role.
The most likely error here is to assign the data operation code to the business logic layer and the database as the data access layer.
For example, some friends feel that the BLL layer is not meaningful, but they just upload the DAL data and forward it to the UI without any processing. Take a look at this example
BLL layer
SelectUser(UserInfo userInfo) gets the user details based on the username or email that comes in.
IsExist(UserInfo userInfo) determines whether the specified username or email exists.
Then the DAL also provides the corresponding method for the BLL call
SelectUser（UserInfo userInfo）
IsExist（UserInfo userInfo）
In this way, BLL does only play a transmission role.
But if you do:
BLL. IsExist（Userinfo userinfo）
{
UerInfo user = DAL. SelectUser（User）；
return (userInfo.Id != null);
}
Then DAL does not need to implement the IsExist() method, and there is logical processing code in BLL.
3、UserModel.cs
Entity, this thing, you may think it is not easy to stratify. Including me, I understood it this way: UI?àModel?àBLL?àModel?àDAL, so it is believed that the Model acts as a bridge for data transmission between the layers. But here, we don't think about things simple, but about complexity.
What is Model? It's nothing! It is dispensable in a three-tier architecture. It's actually the most basic thing in object-oriented programming: classes. A table is a class, a news is also a class, int, string, doublie, etc. are also classes, it is just a class.
In this way, the position of the model in the three-layer architecture is the same as the status of variables such as int and string, and it has no other purpose, it is only used for data storage, but it stores complex data. Therefore, if the objects in your project are very simple, then you can directly pass multiple parameters without a model to create a three-layer architecture.
So why do you need a model, and what are its benefits? The following is what comes to mind when thinking about a question, inserted here:
Can the Model play a bigger role in the passing of parameters at each layer?
When passing parameters between layers, you can do the following:
AddUser（userId，userName，userPassword，…，）
It can also be like this:
AddUser（userInfo）
Which of these two methods is better? At a glance, it must be the second one much better.
When to pass parameters between layers with normal variable types (int, string, guid, double), and what to pass with Model? The following methods:
SelectUser（int UserId）
SelectUserByName（string username）
SelectUserByName（string username，string password）
SelectUserByEmail（string email）
SelectUserByEmail（string email，string password）
It can be summarized as:
SelectUser（userId）
SelectUser（user）
Here we use the user model object to include four combination modes of username, password, and email. UserId can also be merged into user, but other BLL in the project implement interfaces with id parameters, so this item is also retained.
userInfo is passed, so how to deal with it, this needs to be in the order of order, there is a specific code to decide.
Here it is processed in this order
First, see if you have both username and password, then see if you have both email and password, then see if you have username, and then see if you have email. Processed sequentially.
In this way, if a new content is added in the future, the membership card (number), there is no need to change the interface, just add support for number in the DAL code, and then add the performance and processing of the membership card content in the foreground.
4、UserDAL.cs
public IList SelectUsers(): Returns a list of all user information
public UserInfo SelectUser(int UserId): Returns the trusted information of the specified user
public bool InsertUser(UserInfo User): Added user information
public bool UpdateUser(UserInfo User): Updates user information
public void DeleteUser(int UserId): Removes user information
What many people can't figure out the most is the data access layer, which part is considered the data access layer? Some people think that the database is the data access layer, which is not clear about the definition, DAL is the data access layer rather than the data storage layer, so the database cannot be this layer. The role of SQLHelper is to reduce repetitive coding and improve coding efficiency, so if I am used to caring about efficiency or using a non-database data source, I can discard SQLHelper, a part that can be discarded at will, how can it become a layer of the three-layer architecture.
It can be defined as follows: the code related to data source operations should be placed in the data access layer, which belongs to the data access layer
5、IUserDAL
Data access layer interface, this is another dispensable thing, because Petshop brings it and ClassFactory factory with it, so some projects do these two things regardless of whether they need to support multiple data sources or not, and some even do not build ClassFactory but only build IDAL, and then "IUserDAL iUserDal = new UserDAL(); I don't know what the meaning is. This is completely a tiger and not an anti-dog.
Many people have a misconception here, that is, that there is such a relationship: BLL?àIDAL?àDAL, thinking that IDAL acts as a bridge between BLL and DAL, and BLL calls DAL through IDAL. But the reality is that even if you code it this way: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); When executing "iUserDal.SelectUsers()", it is actually the UserDAL instance that is executed, not the IUserDAL instance, so the position of IDAL in the third layer is related to the DAL level.
Through the above introduction, the hierarchy of the three-tier architecture is basically explained. In fact, I have a way to judge whether the three-layer architecture is standard, that is, completely replacing any of the three layers will not affect the other two layers, and such a structure basically meets the three-layer standard (although it is more difficult ^_^ to implement). For example, if you change the project from B/S to C/S (or vice versa), then BLL and DAL do not need to be changed except for the UI; Or change SQLServer to Oracle, just replace SQLServerDAL to OracleDAL, no other operations are required, etc. I originally wanted to add some specific code to the article, but I don't feel it is necessary, if you feel it is necessary, I will add it.
Summary: Don't think that a layer is unnecessary just because it's useless to you, or it's particularly simple to implement, or abandon it, or use it for other purposes. As long as the layers are carried out, no matter how many layers there are, each layer must have a clear purpose and function realization, and should not be swayed by the actual process, resulting in the same type of file being located in different layers. Don't let the same layer implement different functions. |
Posted on 5/7/2015 10:53:35 AM
|
|
|
