Generally summed up the development process of the KM system structure: Due to the lack of enterprise application design experience, the structure has repeatedly revised, spent a lot of time, and some harvests. The first issue: The typical transaction script is featured for small applications, and the development speed is fast, and the system design is simple in small applications. However, with the growth of the system, it is found that a large number of code is repeated. As the demand changes, the workload is large, and it is necessary to overthrow. The second phase: combined with .NET provides the convenience of the record set, using the design method of the table module, and the operation of a particular entity such as user management is packaged. Although the basic operation of some underlying can be reused, the amount of work is reduced. However, in the case where the system is further increased, I can't design it better to enjoy the method of object-oriented. In my opinion, each class is like a toolbox. The third phase: Change to the domain model for design, and now the object has an identifier, which is the biggest difference with the table module. Mapping relationship database data with business objects, thinking is quite clear, and the changes to the demand are more than before. Module Division: 1: Data Access Layer 2: Domain Object 3: Data Map 4: Business Function Interface 5: Business Function Factory Six: Business Interface (Interface with Front End Designers) Seven: Custom Exception Processing 8: Application The configuration management is sleepy, sleeping. The time in the HP internship is also almost the same, so I have to find a job.
