- I have been looking at the three-tier architecture and design model over the past few days. I have read a lot of information about the architecture from the Internet, and I have a theoretical understanding of the three-tier architecture, it's just that there is an idea of software layering in my mind. In fact, software doesn't have to be divided into three layers. The old saying "three" means more than three layers, you can divide it into two, three, four, five, six ...... And so on, there are a lot of hierarchies, but in fact, it is mainly divided into three layers, some of which are to make each layer of the three layers subdivision, the coupling between them is reduced to many layers. For example, you can add an idal interface layer on the Dal layer. In short, it is not important to divide the layers into several layers. The specific layers should be determined whether they are well compatible with the idea of High Cohesion and low coupling.
- Everything stays at the level of thought and theory. It always feels empty, knowledgeable, and flashy, and cannot be used in practice after learning. Practice is the final principle, below I use three layers to implement a login form.
- When I wrote this form, I made repeated changes and refactoring. Because it was a user login verification, I made the changes mainly between the BLL layer and the Dal layer, for the first time, I just set up three layers of UI, BLL, and Dal. The Dal layer implements data access and then returns a DataSet object to the BLL layer, the logic verification of the user name and password is performed on the BLL layer. It feels better to write the password at the beginning. Later, through further research on the three-tier instance classic network is Microsoft's petshop instance and some layer-3 data, I feel that there are still many problems in writing this.
A) the model I added seems useless. B. The bll layer also has database-related code, such as dataset, datatable, and dataadapter, the bll layer is too tightly coupled with the Dal layer. C) if you add new operations such as query, modification, addition, and deletion records, there will be a lot of database operation code, and you should consider abstracting a class, encapsulate the unchanged parts of the database operation code to reuse the code and reduce duplication. D) Why does the object class be returned between layers? I think there are many benefits online. I think it is easy to process tables with a large number of fields, so that functions can contain a large string of parameters. E) in order to reduce the complexity of the Dal layer, the Code logic is clear. The interface in the Dal layer is taken out, and the idal interface layer is added. Then, I thought about the dataaccess class in the Dal layer for half a day, if the classification is based on usage, it should be on the interface. Therefore, this class is also taken out and a dalfatory layer is added to access different databases through the table interface. Dalfactory Layer Code
Idal Layer Code
Sqlserverdal Layer Code
Sqlserverdal-layer sqlhelper helper class
Through this example, I have some understanding of the benefits of the interface, because at first I didn't use the interface. The advantage here is that through the database table interface, different databases can be accessed. In fact, to access different databases, they all implement methods in the interface. This is the key to the interface. Interfaces provide methods and behaviors for different classes to implement, reflecting polymorphism, the result is that the Code and program are extensible and can respond to changes in requirements. Of course, if you are sure that the requirements will not change before writing a program, you can skip the interface. The benefits of interfaces are far more than that. Interface-oriented programming can achieve high cohesion and low coupling. For example, The bll layer accesses the Dal layer through interfaces, making it easy to replace the database, the IOC (inversion of control) inversion is also called dependency injection) + reflection + XML application configuration files to change access to different databases. To achieve this function, we actually use a design pattern abstraction factory. I feel that the design pattern is too flexible, the key to how to use it is to make good use and use it properly. Whether or not to use this mode to solve the problem should be the correct application design mode. During and after the process is completed, I feel that the process is complicated and the idea is a bit messy. I want to draw a UML diagram. If I use a diagram, the code structure will be very clear, the next task is to draw examples, class diagrams, and so on. When the picture is almost done, you can come back and write the code. In short, a login form is different from a previous understanding of many concepts. some concepts, such as interfaces, design patterns, and encapsulation, are different from previous understandings, teacher Mi and the students have always said, "learning is really a process." Now, I understand it a bit. Learning cannot be achieved overnight. I need to understand it in the process, but I cannot understand it, but the learning process.
