A general analysis of the Spring MVC framework in depth

In today's MVC framework, it seems that WEBWORK2 is gradually becoming mainstream, and the combination of webwork2+springframework is becoming more and more popular. This seems to imply that spring's own MVC framework is far worse than WEBWORK2, so everyone is replacing it with WEBWORK2. Indeed, Spring's MVC framework is not a central part of the whole spring, but it's more powerful than many people think. Many people including XIECC think that spring's MVC framework is excellent, even better than WEBWORK2.

Here's a list of some of the important decisions that spring's MVC framework makes at design time and compare it to the relevant MVC framework such as WEBWORK2 or struts:

The entire MVC configuration of spring is based on an IOC container

Compared to struts or WEBWORK2, this is a somewhat strange decision of MS, looking at the configuration file of spring MVC, first seeing not action or form, but some bean,bean with a specific name. The following configuration is a simple or somewhat complex attribute. What we see is a machine's easier data structure than an element that is easier for people to understand.

But this is exactly the root cause of spring's MVC! Because its configuration is the configuration of spring's core IOC container, which means that all the power of the IOC container can be shown here, and we can expand and enhance spring MVC as we like, and we can do it in other MVC Many unimaginable tasks in the framwork. Do you want to extend the new URL mapping? Do you want to change the implementation of a themeresolver or localreolver? To display a new type of view on a page (for example, RDF, huh, a little secret: XIECC is a research semantic web, although all day, do not write papers, Write gossip only)? Do you even want to define AOP directly in controller? These are a piece of cake for spring's MVC.

I have not studied the extension mechanism of WEBWORK2, and I know that through the interceptor mechanism of WEBWORK2, many extensions can be made, even a simple and simple IOC container. But no matter how powerful it is, the number of extension points is provided. Its power is hard to compare with the real IOC container. The plugin function of struts is known for its excesses, although it also provides a plugin mechanism.

Another reason for spring's adoption of the IOC configuration is that it is easy to integrate spring's MVC with the spring's IOC container. Spring provides consolidation with struts and WEBWORK2, but this integration requires indirect packaging, and it's not always natural. It also leads to a concept of multiple configurations, and WEBWORK2 needs to configure the Bean in spring and then configure its own xwork files. Imagine that our bean is directly a controller, and it's a lot of fun to be able to do all of the MVC tasks directly.

Another reason Rod Johnson uses the IOC container is that it reduces a lot of development effort. Look at the UrlMapping bar, it provides the property itself is a hashmap, only the configuration is complete, our beans in the data will naturally exist, haha, good. Instead of parsing XML like struts, read its contents one by one to HashMap.

This configuration is a bit weird, but if we are very familiar with spring's IOC container, we find it very cordial and very simple.

Finally, it's a simple little secret, how does spring know that the configuration of a bean is urlmapping? The other bean's configuration is viewresolver? In fact, it's very simple to read all the beans into memory and then look through the bean's name or type. To find by name is simply the Getbean method, and the static method of beanfactoryutils.beansoftypeincludingancestors is used to find by type.

Spring provides a clear model, view concept and corresponding data structure

An interesting data type in spring is called Modelandview, which simply encapsulates the data to be displayed and the results displayed in a class. But it provides a clear concept of MVC, especially the enhancement of the model concept, which makes the logic of the program clearer.

Remember when I used to write in struts, in order to show the data I often put things into httpsession or httpservletrequest (or set to form, though not very useful), which caused the blur of model concept, It also leads to a tight coupling of struts and JSP pages. If we want to replace the veloctiy, we have to add a plugin, because the data in velocity does not need to be placed in the request.

WEBWORK2 emphasizes the simplicity of decoupling with the web framework and its command pattern, so there is only a simple get or set method in its action, and if the data is returned, it simply returns a string. Of course, this implementation has its advantages, but it dilutes the model and view concept. Rod Johnson believes that the action and model functions are included in the WEBWORK2, so that a class has too much responsibility and is not a good design. Of course Jason Carreira not agree with this view, because the model object in action can be delege to other objects. But in any case, the root of this argument is that Webwork2 the concept of model, view, and even the web. The people of the beholder, the final result or see a person like it.