Some negative factors of spring in Java programming

I. The xml configuration of spring is poor. XML abuse has been rampant. You need to know Program The most popular is reading. Code . When looking at a business logic, I found that I had to look at its parent class first, then the grandfather class, and then the grandfather class. Finally, I found that I still needed to find another class through spring configuration, when this class ref has another class, it must have been fainted. Whether it's a beginner's language, a master who has a deep understanding of technology, or a Member who has been drawn from other places because of the project. Simple code and configuration are all appropriate (for Java users who have been using xml configuration for several years, such as me ).

II. The spring configuration method does not support the development mode. Every time you modify the spring configuration, you always need to restart. It is very time-consuming to start some large projects. On the contrary, some other small third-party configuration Development Kits support the development mode. In addition, I think sping is unlikely to Support the Development Mode.

3. Intuitively, there are too many spring pipes. For many frameworks or third-party Lib, it is often devoted to completing one aspect of the system. For example, Hibernate is devoted to o/R Mapping, and EJB is devoted to distribution, transactions, and rule engines. If spring is doing too much, it is suspected that everything is not doing well. Of course, this is not the main negative factor, but it interferes with the business system. The management of objects may allow some users to use spring to manage business objects. This may bring negative results. For example, Struts MVC is taken over by spring, and business logic is taken over by spring. A newbie can hardly understand the code. When you understand the code, there will always be a "black hole ". As mentioned above, because of the dependency between business objects, "Restarting Business Objects" is very complicated, and spring cannot do this. Unless your Business Objects yield to the spring architecture, this is against the original intention of using spring. Another example is that the complexity of the Business Object determines that spring is difficult to manage and there is no need to do so.

4. Adapter disaster. Spring has to make some adapters to manage third-party packages. To facilitate management. Of course, some third-party packages are very simple and don't need to be done. For example, I saw a new article in javaresearch.org.ArticleThe timer is used in spring. But some complicated third-party packages or frameworks have problems. You have to write the adapter. For example, take over a web MVC framework. As mentioned earlier, the timer lib has its own configuration. You need to go to spring to manage it. Only one adapter can be written, and the configuration file provided by the timer lib can be used in the adapter.