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.

　　Third, spring controller is singleton, or thread unsafe

Like struts, Spring's controller is singleton, which means that each request comes with the system using the original instance, which leads to two results: we don't have to create controller each time, Reduced time for object creation and garbage collection; Because there is only one controller instance, when multiple threads call it, the instance variables inside it are not thread safe.

This is also where WEBWORK2 boasts that every action is thread safe. Because every request comes up, it creates an action object. Since the efficiency of the modern JDK garbage collection is no longer a problem, the pattern of throwing away an object has been recognized by many people. Rod Johnson even used this as an example to prove that the object pool function provided by Java EE is of little value.

But when people brag about how important thread safety is, I wonder how many people have to consider thread safety? Rod Johnson also raised other issues when analyzing ejbs, not that the world would perish without the EJB thread-safety magic, and that in most cases we would not have to consider thread-safety issues or the object pool. Because we don't need to keep the instance state in most cases.

At least I've written so many struts Action, I've written so many spring Controller, and I've barely encountered a problem that needs to be kept in instance variables. Of course I didn't write enough code, and Struts's designer Craig R. McClanahan once said that when he was designing struts, two conditions were immature: there was no test-driven development concept; The JVM's garbage collection performance was too much. If redesigned now, he will also use each request to generate a new object design method, which can solve the problem of thread safety.

　　Spring does not hide servlet-related elements such as httpservletrequest or HttpServletResponse as WEBWORK2 or tapestry

This is another important design decision. In WEBWORK2 we have no httpservletrequest or httpservletresponse, only the getter, setter, or actioncontext data, which results in a clean action, An action that is completely unrelated to the web, a bean that can run independently in any environment. So what does WEBWORK2 's command-mode action bring to us? I think there are two main points:

1, it makes our action can be tested very easily.

2. Users can add business logic to the action and be reused by other classes.

But by comparing it with spring, we find that the benefits of these two-point features are not as significant as we might think. Spring's controller class can also be tested very easily, look at the package below Spring-mock, it provides the mockhttpservletrequest, Mockhttpservletresponse There are other classes that make testing controller easier. Take a look at the business logic in the action, Jason Carreira once said that we can heartily add business logic to the WEBWORK2 action, because the action is not dependent on the web. But how many people actually add business logic to the action? Most people will have business logic delegate to another service class or manager class. Because we know that adding business logic to action will make the layered architecture of the whole system unclear, anyway, the Web layer is the Web layer, the business layer is the business layer, and the logic of the two is mixed together always brings the problem. And adding business logic to action will use this action class to become huge, and the WEBWORK2 action is to create an instance of each request, although the performance impact is not too great, but does not mean that each time the business logic to new out, The business logic should be a single case in most cases.

Not to show the request and response to the user, of course, will also bring loss of functionality, perhaps the general situation, with the WEBWORK2 provided by the interface is enough, but sometimes we have to know that request and response can play a greater power. For example, one of my previous projects had a dynamically generated tree-like page on a JSP page that showed recursion as painful or impossible, so I response the page directly, which is easy in spring, but it may be difficult in webwork ( I am not sure, I did not study deep enough, perhaps the master is a way.

　　V. Spring provides a good but inadequate interceptor mechanism

Looking back at struts, it does not even give us the opportunity to hook point in the architecture, and we have no chance to join our interceptor. We can only do a bit of limited scaling by overloading the Requestprocessor class of struts.

To WEBWORK2, it seems that interceptor suddenly became the core of the entire framework, except for the core parts of the action, all the other things are interceptor. Its powerful interceptor capabilities make it easy to extend the entire architecture. Some people call this interceptor Aop,jason Carreira proud to claim that this is called Pragamtic AOP. I don't agree that this is AOP, it's just a simple interceptor mechanism. But whatever it is, its interceptor does have a powerful function.

Spring also provides its interceptor mechanism, its handlerinterceptor three interceptor methods: Pehandle, Posthandle, Aftercompletion. corresponding to controller before execution, after controller execution and page render. Although it is sufficient in most cases, it is clearly not Webwork2 powerful in terms of functionality. From the AOP point of view, it does not provide around interceptor, but only before and after interceptor. This means that we can't keep the state before and after the interceptor, in the simplest case, if we want to calculate the execution time of a controller, we have to hold the begintime state after the execution of before, and then put it out in the post. But obviously this state remains a problem, and we can't put it in the instance variable because interceptor is not thread safe. Perhaps through threadlocal can solve this problem, but such a simple function to use this method to deal with, obviously the interceptor itself design is still somewhat problematic.

　　Spring provides multiactioncontroller so that it can contain multiple action in a class

The design is somewhat similar to the dispatchaction of struts, but provides a more flexible mechanism. When our project becomes larger, it is worth it to put the same function in the same action. Webwork2 lacks such a mechanism. If you look at spring's source code, you will find that in fact, the amount of work to achieve multiactioncontroller is relatively small, but the reflection mechanism to the resolution of the name of the implementation of the method is finished. In fact, WEBWORK2 can also provide such a mechanism. It's not very elegant in design, but it's really useful.

　　Seven, Spring offers more options

Look at the controller provided in spring, which offers a lot of different controller classes. Do you want to generate wizard? Do you want to dedicate the form to the controller? The class to hold multiple methods? Spring provides a rich subclass to extend these choices. Of course, we can also easily expand these features ourselves.

Take a look at spring's viewresolver, which offers countless different types of viewresolver. More importantly, we customize the way we map our pages. Look at the strtus, look at the WEBWORK2, there will be a page and forward name of a layer of indirect conversion, we have to configure a string in the configuration file (typically success) corresponds to that page. But we have more freedom in spring, we can adopt WEBWORK2 strategy, and we can adopt a simpler strategy, such as removing the JSP file name from the extension mapping method. Some people may think this kind of mapping is naïve, but I think it is a very useful way, even in big projects.

Is there a new extension? Look at the spring Web Flow bar, which is a subproject of springframework. It provides a configurable implementation for a long list of wizard pages based on page flow. In spring 1.3, it will be part of the springframework.

　　The tag of spring

Although spring's tag count is pitifully small, it is carefully designed. Its goal is simple: make it easy for the artist to edit the page. Because the text is still text,checkbox in the Spring page, it's not like tag in struts or WEBWORK2. It only uses the Springbind to carry on the packing to the input content. So although the page display code will be more than WEBWORK2, but this is definitely valuable.

In the next few chapters, I'll analyze how spring makes our web apps have access to the IOC container without having to know ApplicationContext, and then a simple source analysis of the design and execution of spring, and then a few extensions spring Method of MVC.