The management system the company has recently built, because I feel that the system framework design at work is very unreasonable, resulting in a very long development cycle. I have different design concepts from the team leader, and the communication is fruitless, and I almost quarreled several times. Think of the programmer's saying "Talk is cheap, show me the code", so I want to use my spare time to redo the project, and I also want to take this opportunity to exercise and test my ability to complete the project independently.
First of all, I will summarize some of the main failures in the current system in my opinion:
- Permission system: In my opinion, the permission system is the most unreasonable part of the design of this work project. Because of special requirements, each module of each project must be separately authorized and managed, similar to ACL, and the existing RBAC model cannot meet it. The team leader wrote a permission system by himself. Basically, the general principle is to write an interface, use various judgment permissions as a method, and then write judgments for each sub-module, write a ModelAttribute method, intercept all Controllers, and get the query parameters. Project ID, and then go to the database to query the permissions of the corresponding project, and the front desk uses the c:if tag to determine the permissions. I think the main disadvantage is 1. Severe coupling, which is coupled with module management and process management in many places, and a lot of methods need to be added to each controller. 2. Depends on parameters, because ModelAttribute's method is to intercept all methods in the controller. After the permission system is written, we spend a lot of time modifying the Controller and the front page. 3. The code is bloated and debugging is difficult. Each has a separate permission class. The permission method is hard-coded in the subclass, which is very troublesome to write. Moreover, when debugging permissions in the foreground, you need to reverse the background and breakpoints. 4. Superfluous development. I proposed to integrate the project role into the system role before, but it was rejected, which is equivalent to writing an additional set of management entries.
- Model design: too rigid in the three paradigms, too many tables are classified, the number of tables is reduced, but the development difficulty has increased exponentially.
- Project module: Modules are hard-coded in the code, including the structure of the module, links, etc., and it is very troublesome to modify.
- Process management: Process management does not use workflow or design patterns, and is seriously coupled with the permission system, which leads to a lot of logical judgments and methods in each Controller.
- Code generator: The code generator function of jeesite itself is relatively not powerful enough, and it has not been fully utilized in actual development.
- Demand management: I think the development system needs a lot of communication with users in the early stage to find out the actual needs of users. The role division of this project development is not obtained until the end of the project, which is different from the previous form.
Based on the above points, my new design concept is as follows
- Avoid repeated wheel building as much as possible. Wheel building requires a good foundation and design mode, and the debugging and development cycle is long, so it is easy to dig holes for yourself. Simplify the design as much as possible. For the same function, there may be several feasible solutions. Consider several more, and choose a simple solution as early as possible. Apply design patterns, reduce coupling, follow the single responsibility principle, open for extension and closed for modification. Finally, make the most of your code generators as much as possible.
- Based on the above, the framework I first selected was Jeeplus, and I bought a version without workflow for 120. At first, I liked his style, but after trying it out, I found that his code generator is very convenient and improved than jeesite. The place is database validation and custom object query, which are very useful functions.
- Permission system: In the first version, I consider adding projectId to the required path, so that you don't have to worry about the parameters, but you still need to use ModuleAttribute, and you can't use a code generator, you need to write a lot of things, and it is possible There is a major drawback because it is two verifications, which may lead to transfer of permissions. I have no idea how to solve it. The second version of the plan is to consider using AOP, and add judgment before the method that requires permission filtering. The disadvantage is that it is inconvenient to apply in the front section as before. The third solution is to use shiro, which should be the best way in theory, but how to target a single resource, I haven't thought about it at first, and later after consideration and experimentation, I found that the permission string itself can be supported, as long as it is designed how to add it Variables to judge and how to authorize. This method, once the design ideas are straightened out, is definitely the most convenient solution for development and transplantation.
- Model design: I intend to retain redundant fields to a certain extent, which violates the third rule in the three paradigms: For example, this budget estimate table has 8 details at the bottom. In addition to the basic attributes, there are several details in these 8 details. The price field, if strictly in accordance with the three paradigms, the price is made into a sub-table. Now it is unreasonable in the actual development process. If only the main table and detailed table are kept, the code generator can be used directly, and the query method is simplified. There is also a lot less logical judgment. In the last project, there was a similar dispute with the team leader. He took out the reported years separately and made it into a parent table. In this way, the report becomes the project->project-year->report three-tier data, which increases the difficulty in query, transmission, logical judgment and so on. I think age is fine as an attribute of the report, and the reduction in development difficulty is at least multiplicative.
- Module page: It is planned to do a separate module management. The modules are divided into two categories. The main module is equivalent to a group. There is no direct page, sub-module, and entity module. There are attributes such as page color icons. In this way, it is convenient to manage and persist, and you can change the icon link on the web side at any time without changing the code. When loading a module, determine which ones can be displayed and which ones are hidden according to the permissions. What needs to be further thought and solved in the development is how the module is linked to the role, how the role is linked to the user, and how the project authorizes the user. There are many possibilities at each step, and improper design will multiply the design difficulty. At the beginning, I planned to apply the combination mode I learned recently, but I found it unnecessary, and I could easily traverse it. Increasing the mode would increase the difficulty of development.
- Process management: Because the permission system is stripped out, the process is relatively less difficult to develop. Decided to use the state mode to achieve, in order to reduce a large number of logical judgments such as if else in the code, and it is also easy to expand when separated. In addition, although I didn't read the process design in the original system in detail (and I can't understand the code written by others), but from the observation and analysis of the database, I believe that there is no need to separate the approval opinions into separate tables---I don't know what the basis is when designing Considering this, review and comments are one-to-many, maybe because there is an action that only fills in comments and does not approve? I think one approval action corresponds to one log, and one approval action has one opinion. It is estimated that it is not easy to implement with ordinary logic. In this case, the benefits of the state machine are reflected. Jumping to the original state can also be regarded as an action, and the approval process can be recorded in order.
- Code generator: Because the selected framework is good and some model designs have been changed, I expect to develop the budget table within a day (it turned out that I used it for at least a week, and I spent a lot of time modifying the style and debugging later)
- Reporting system: This refers to the budget statement, and I plan to use the observer pattern to decouple it.
- Others: The original project uses the upload and download system developed by myself. I don't use it much. I plan to implement it with the project's own.
Modules and functions that are not ready to be completed include:
- Modules other than projects, general additions, deletions, revisions, and project budgets are generally the same as the budget estimates.
- Report overview and export: The common file previews used in the current project are pot and docx4j, which are not very good in style. The project report uses ureport2, which occupies more memory. I will pay attention to whether there are better tools in the future.
- Upload and download persistence and encryption: I feel that it is meaningless to save the file name in the database, and encryption is meaningless, because the key is saved on the server. If you get the server permission, you can also get the secret key, and decryption is not a problem. , and it is not convenient to migrate later.
- Data obsolescence: The function is not complicated, it is just a mark, and there is not much room for improvement.
- Project planning tasks: I haven't touched this module, and intuitively it feels like manual work, and there are not many places to optimize the architecture.
Areas to be learned and improved in the future:
- Workflow: Although the state machine is good, there are some problems, for example, it cannot be configured and cannot solve some complex problems. Try to use activiti in future projects, or try other modes yourself.
- springboot: I plan to try some more frameworks, such as springboot with sub-modules, such as frameworks that support the separation of front and back ends of restful, such as guns
- Online excel editing: See if you can find a framework similar to vaddin-spreadsheet. Many functions in this project are actually marked with the company's excel sheet. This framework has excellent effects and is easy to bind, but the disadvantage is too cumbersome, with both front and back ends. The framework, and can not be separated out the front end to use with springmvc alone.
- Other design patterns. This is also the first time to use the design pattern in an actual project. Although I have followed the book to understand it, there are still many problems in actual use. I hope that it will be used in projects in the future.