A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
The three-layer Implementation of message and view messages is not discussed from the theoretical point of view. L3 Architecture It uses an example to describe how to build a three-tier architecture project and describe the levels and functions of each file in the project. The purpose of writing this article is not to show how many of your methods are correct, but to help those who are new to the three-tier architecture but do not know where to start. Because online Article Most of them focus on the introduction of theory, while ignoring specific practical applications, or some examples, but they are not thorough. As a result, I learned it again theoretically, but I still don't know. Code How to write. So I want to start from this aspect, so that beginners who have never done three-tier architecture can also write code. The article expresses my personal understanding of the three-tier architecture, and there must be many shortcomings. You are welcome to correct me. The younger brother will modify this article based on feedback. The code in this article is pseudocode, which is only used to clarify ideas.
1. AddASP. NETWeb application project named UI. Create a web form file user. aspx (including user. aspx. CS)
2. Add the classlibrary project named BLL and create the class file userbll. CS.
3. Add the classlibrary project named dal and create the class file userdal. CS. Add sqlhelper reference. (This is Microsoft's Data Access class, or you can directly write all the data access code without using it. I generally use my own data volume class dataaccesshelper ).
4. Add the classlibrary project named "model" and create the class file usermodel. CS.
5. Add the classlibrary project named idal and create the interface file iuserdal. CS.
6. Add a classlibrary project named classfactory.
As you can see, this is no different from the petshop example, and it is simpler, because it is also used to learn the three-tier architecture through petshop. However, some friends may be vague about the levels of these projects and their relationships. Here we will explain them one by one:
1, User. aspx andUser. aspx. CS
These two files (and the project to which the file belongs, which is also the case below and will not be repeatedly emphasized) are part of the presentation layer. User. aspx is easy to understand because it displays the page. User. aspx. CS some people think it should not be counted, but should be included in the business logic layer. If there is no hierarchy, it is okay to let user. aspx. CS Process the business logic, or even operate the database. If there is hierarchy, it is not necessary. In the layered structure, user. aspx. CS should only process content related to the display, and other content should not be involved.
For example, if we use the list function to display users, BLL is used to extract information and UI (in this example, user is used. aspx. CS) after BLL is called to get userinfo, bind it to the user through code. on the data control of aspx, the list is displayed. User. aspx. CS does not play any role in the UI. It is only used to transmit data, and most of the actual code is implemented in this way, so some people think that user. aspx. CS should not be regarded as the UI, but should be incorporated into BLL for logical processing. Looking further, a new requirement was raised, asking for an icon in front of each user to vividly show the user's gender, and the Child icon is used to represent the person younger than 18 years old. The implementation of this requirement is the result of user. aspx. cs. In this case, user. aspx. CS is actually used.
Add the following method:
Public ilist <userinfo> 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): new 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 used to process operations related to the business logic. Many may think that the only purpose of this layer is to forward data transmitted from the presentation layer to the data layer. This is indeed a lot of cases, but it can only show 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, it only plays a role in forwarding. However, this does not mean that the business layer is dispensable. As the project increases or there are many business relationships, the business layer will reflect its role.
The most likely cause is that the data operation code is divided into 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. They only forward the Dal data to the UI without any processing. Let's take a look at this example.
Selectuser (userinfo) obtains user details based on the input username or email.
Isexist (userinfo) checks whether the specified username or email exists.
Then Dal also provides a total of BLL calls.
In this way, BLL does play only one transfer role.
However, if you do this:
Bll. isexist (userinfo)
Uerinfo user = Dal. selectuser (User );
Return (userinfo. ID! = NULL );
The Dal does not need to implement the isexist () method, and The bll contains the logic processing code.
Entity class, which may be hard to be layered. I used to understand this as follows: the UI has a model has a BLL has a model has a dal, so that the model serves as a bridge for data transmission between layers. But here, we don't want to make things simple, but to make things complicated.
What is model? It's nothing! It is dispensable in a three-tier architecture. It is actually the most basic thing in Object-Oriented Programming: class. A table is a class, a news is also a class, Int, String, doublie is also a class, it is just a class.
In this way, the location of the model in the three-tier architecture is the same as that of the int, string, and other variables. It has no other purpose and is only used for data storage, it only stores complex data. Therefore, if the objects in your project are very simple, you can build a three-tier architecture by directly passing multiple parameters without using the model.
So why do we need a model? What are its advantages. The following is what I think of when thinking about a problem, which is inserted here:
Can model play a major role in parameter passing at each layer?
When passing parameters between layers, you can do this:
Adduser (userid, username, userpassword ,...,)
You can also do this:
Which of the two methods is better. Obviously, it must be much better than the second one.
When can I use the common variable type (INT, String, guid, double) to pass parameters between layers? What can I do 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 follows:
Here, the "user" model object includes four combination modes of the three parameters "username, password, and email. Userid can also be merged into the user, but other bll in the project implements interfaces with the ID parameter, so this item is also retained here.
After userinfo is passed in, how should we handle it? This should be in the order of order and determined by specific code.
Processing in this Order
First, check whether there are both username and password, then check whether there is both email and password, then check whether there is username, and then check whether there is email. Processing in sequence.
In this way, if you add a new member card (number), you do not need to change the interface. You only need to add support for number in the Dal code, then, you can add a membership card to the front-end to display and process the content.
Public ilist <userinfo> 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): Updates user information
Public void deleteuser (INT userid): Remove user information
What most people are confused about is the data access layer. What is actually 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. Some also regard sqlhelper (or its similar components) as the data access layer. It is also a dispensable thing. sqlhelper is used to reduce repetitive coding and improve coding efficiency, therefore, if I am used to efficiency or use a non-database data source, I can discard sqlhelper. How can I become a layer-3 architecture that can be discarded at will.
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.
Data access layer interface, which is a dispensable thing, because petshop contains it and the classfactory class factory, so some projects do not need to support multiple data sources, both of these two items are involved, and some do not even build classfactory but only idal, and then "iuserdal = new userdal ();", I do not know what the meaning is. This means that it is completely difficult to draw an anti-type dog.
Many people may have a misunderstanding that BLL has idal and idal serves as a bridge between BLL and Dal, bll calls Dal through idal. But it is actually even if you code it like this: "iuserdal = classfacotry. createuserdal (); ", then the" iuserdal. in selectusers (), the userdal instance is actually executed, rather than the iuserdal instance. Therefore, the idal position on the three layers is in a level-1 Relationship with the Dal.
Based on the above introduction, the hierarchy of the three-tier architecture is basically described. In fact, I have a method to determine whether the layer-3 architecture is standard, that is, to completely replace any layer in the layer-3 architecture, will not affect the other two layers, this structure basically conforms to the layer-3 standard (although it is difficult to implement ^_^ ). For example, if you change the project from B/S to C/S (or vice versa), you do not need to change BLL and Dal except the UI, or change sqlserver to Oracle, you only need to replace sqlserverdal with oracledal, and no other operations are required. I wanted to add some specific code in the text, but it doesn't feel necessary. If you need it, let me add it.
Conclusion: Don't think that a layer is useless to you, or it is very simple to implement. Think that it is unnecessary, abandon it, or use it for other purposes. As long as the layers are layered, each layer must have a clear purpose and function implementation, rather than being left or right by the actual process, resulting in the situation that the same class of files are located at different layers. Do not enable different functions at the same layer.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service