Summary of VB. NET data room Charging System

Once again, the data center charging system was summarized as VB6 for the first time. This time, VB. NET + design mode + Layer 3 were used.

The data center Charging System of VB6 is designed for process-oriented development, with a large amount of code and difficult to maintain. net is object-oriented development. Although the amount of code is not reduced, the structure of the system becomes more flexible and the maintainability is improved a lot. The hierarchical and design modes are adopted, the Reuse Rate of each module is greatly improved. For more information, see. I checked the information on the Internet and started my 3-tier tour after I had a brief understanding of the 3-tier. I used EA to draw a three-layer logon example. The following is my system architecture (package diagram ):

At the beginning, only the UI, BLL, and Dal felt too monotonous, and the flexibility was too poor. They felt the system was dull, therefore, the abstract factory + reflection + configuration file is used to improve the flexibility of business and database operations. It took me nearly two days to perform a single reflection. Finally, I found that there were no reflected objects in the path. I put the DLL generated by layer d in the debug of the U layer to successfully reflect the reflection, because the encoding needs to be continued at Layer D, a reference is added to layer D at the U layer, so that layer D can be re-compiled at each compilation, the DLL of layer D is automatically copied to the debug folder of the U layer. Since it involves the development of databases, database operations are inevitable. For every addition, deletion, modification, and query of databases, some fixed methods need to be called, and there are a lot of repetitive work, therefore, the common database methods are extracted as a new layer. Operations on each layer D are implemented by calling sqlhelper. This reduces a lot of repetitive work and reuse rate... You know. Before writing the code, I asked depeng about how to write the code at so many layers. What should I write first? I don't feel that I should write one for three layers separately, or I should write them all at Layer 3 of the functional module. In the future, cooperative development must be written separately. However, this development is a personal development, and it is the first time to write hierarchical code, write in three layers of functions, and debug while writing, errors can be detected in a timely manner. For a function module, I first write layer d, then write layer U, and then write layer B. In this way, the logic will be much better. The fee system of the IDC is extended on this login instance. It is essentially the same. I just wrote several more functional modules. The report has not encountered any major problems except the one-day tangle. This code writing should have been completed in about a week, and the result is used for 10 days. It is mainly because the sequence diagram at that time was not well considered and many judgments were added when the Code was written. A lot of time is wasted. After that, of course, I still feel that I am not doing well. For example, the Dal layer should be constructed based on tables in the database, that is, designed based on the entity class. However, during code writing, it is found that except for entity classes, most of them are similar and even have the same structure. If a local error occurs, all of them have to be changed. Yesterday, I also discussed it with yunjie. She put forward a point of view-using generics. For object classes, we use objects instead, and then re-design layer D through analysis, abstraction, and fusion to simplify layer D, reduce the amount of code, and improve the Reuse Rate and maintainability. However, the difference still exists. re-design requires careful consideration and scrutiny to verify its feasibility. There are also disputes over the sqlhelper class. If the sqlhelper class is used as a class library for other components, it can belong to one component, and the component should be placed in the build diagram rather than the package diagram. If sqlhelper is only used for calling layer D, you can put it in layer D. Therefore, sqlhelper is a separate layer, which is controversial. There are still many questions: layer D is designed based on database tables, while the U layer is designed based on use cases. What is the design of layer B ?? By table? By Use Case? By business ?? If a table is used, one entity class at Layer B corresponds to one class at Layer B. However, for the recharge function, at least two tables (card information and recharge record) need to be operated ), and the table corresponds to the classes in the B-layer, so how does the logic of the B-layer work? Add a appearance Layer ?? What is the use of layer B? Isn't the appearance layer the business logic layer ?? If the use case is used, the granularity of the required use case cannot be too large, otherwise it will be omitted at Layer B. By business, you still need to think about it. The data center charging system has come to an end this time. We look forward to cooperating with developers to solve these problems. I am very grateful to you for your questions.