Do not let the open-source architecture replace our design

There are many open-source frameworks. Everything. But can we solve our design problems once and for all by using these open-source frameworks? I think the answer is no.

Without understanding the design and system, framework abuse is inevitable.For example, Hibernate (hereinafter referred to as hi) is an object persistence framework. Its purpose is very simple, and it is to provide Object Persistence means. However, in my daily work, I often see that many people use hi very complex and want to use hi to implement some complex database queries, it seems that hi is regarded as a database abstraction layer. Use hi, but never forget SQL. I think this is incorrect. Although the essence of HI is Orm. But it is not used to replace the database. Do not use hi as a database. During design, we should consider the differences between objects. Those are business objects and those are data. If it is data processing, we can use data operation encapsulation such as criteria to operate data. Even directly using SQL statements, our perspective changes at this time, instead of staying on the business object. Data means that data is not dependent on objects, which is better. Making a pojo without moving is not a good habit. In addition, if we want to transform the original system, we recommend that you use the open source orm of cayenne and Apache with your own manager, which can automatically extract pojo from the database.

If we design the system from the beginning, we recommend that you do not refer to the database any more. Change the relationship between database tables to the relationship between objects and write programs to maintain the relationship between objects. We recommend that you use di (dependency injection, the key is the size of your system. Tables in the database should be as simple as possible, and should be divided into dimensions and facts for reuse. (We suggest you understand some data warehouse concepts) Reduce the number of fields in the table. If you use a multi-dimensional structure to design a database, there are not many fields in the table. The quality of the design depends on your years of experience and understanding of the customer system. (Analysis of those dimensions and facts is not an easy task. People who have done this know it)

I am very careful about the application of the framework. If we do not understand the background of these frameworks, using these frameworks will inevitably lead to various problems. So what are the principles of good and bad? I think the authors of better, faster, and lighter Java talk very well: Keep it simple, do one thing, and do it well, strive fortransparency. The translation is:Keep simple, do one thing at a time, and strive for Transparency. In fact, at least what a good framework needs to do is transparency. Some people call it non-invasive. For example, spirng. (Spring was criticized for saying that it did not actually do anything. I feel the same way.) In fact, the intrusion is not a framework issue, but a self-designed issue. We should make our own interface to the introduced framework in our design, so that we can get rid of the Framework intrusion troubles.

Finally, I want to explain what the advanced Web application framework should look like. FirstIt must be restful.All things are resources, which can avoid session troubles. Second,It must be service-oriented, That is, the so-called SOA, which can achieve loose coupling and implement functions similar to those of components. The view part must be Ajax, but also componentized. the ready-made method is ext + buffalo. However, you can also use other interface methods, such as net winform or Java swing. Finally, an object manager is responsible for managing business objects. The AOP method is used transparently to integrate logs, tasks, permissions, transactions, and workflows. Each part is independently configurable. You can configure them as needed in our application. Finally, a distributed solution is provided to cope with scalability. In addition, we recommend that you minimize the number and number of configurations and provide configuration tools as much as possible, rather than hand-writing xml configuration files.

 

Author: Cui Gang