Simplified Spring (3) controller layer

Struts and WebWork Fans please skip this article.

Isn't MVC separating M, V, and C? To the materialistic simplicity of the practice is two JSP a responsible view, a responsible controller, plus a responsible for model Java Bean, already can work very well, then everything is simple.

And now for some not essential features, there are so many non-standard web framework, it is a bit depressing. Simple development, like Ruby on Rails, is not available, and there are not too many limitations to learn, such as the WebWork model to consider. But the more you use the frame as struts, the more troublesome it is, or the tendency to have a serious tapestry like the one on the forehead, the amount of a "master-specific toy", used in the team is irresponsible behavior.

So, my MVC solution is to use the controller interface of spring MVC, write the most common JavaBean as controller, essentially the same as the JSP as controller, but with the characteristics of spring IOC.

The reason for this negative selection criterion is that this generation of MVC framework is far from the standard of returning to the RAD era, destined to be just a short, transitional technology that is not worth investing too much energy and team learning costs.

1. Principle

Spring MVC, according to plant taxonomy, is a statically configured front controler in the Martin Flower〈 Enterprise application model, using Dispatchservlet to intercept all *.do requests, according to the configuration of the XML file, Invokes the HandleRequest (request,response) function of the corresponding command object, while simultaneously injecting the dependent object.

Our controller layer is the ordinary javabean that implements the HandleRequest (request,response) function.

2. Advantages

The advantages of Spring MVC compared to struts:

One is that its controller has a loosely-tight class hierarchy, and the user can choose to implement an interface with only one handlerequest () function, or it can use a Simpleformcontroller class that has many callback functions.

Second, do not need form beans, and do not need to tapestry that object-oriented page objects, for the deep fear of class expansion, change a thing to move n places of the people most suitable.

Third, do not need strong XML configuration file, declarative programming is good, but if forced into a framework, what should be declared in the XML, write the time cumbersome, look at the time also want to see the code configuration to understand the more trouble.

What about the webwork? No actual combat, but because the MVC framework is not much, the spring MVC alone controller can meet the needs, there is no more than a set of webwork to set a hurdle for the team, and for future maintenance, spring, The version upgrade between WW2 is troublesome. There's really nothing to add, the Spring MVC source code is very small and easy to control and expand.

3. Simplification

3.1. Direct implement Controller, realize HandleRequest () function

First of all, simple form controller Not my good, not simple. So sometimes I directly implement the Controller interface. The unique function of this interface is the HandleRequest (request,response) for front controller invocation.

If you need to application objects, such as to use Application.getrealpath (), you must extends Webapplicationobjectsupport.

3.2. Each controler is responsible for a set of related action

I'm a strong supporter of a controler. Responsible for multiple action, a controler an action is as boring as a function class. So I used the most traditional way, with URL parameters such as msg= "Insert" to a group of related action to a controler control. Ror and groovy on rails are in this mode, and spring has multiactioncontroller support.

All three of these are direct reflection of the URL parameters to the controller function, while the stripes design can be annotation annotated URL action to response function mapping.

The choice of 3.3.xml declarative programming

My choice is simple, spring has no coercion, I just put things into XML dynamically when I might need to change something without recompiling. The JSP path and the like are all returned to the controller definition.

3.4.Data Binder

The Data binder is a necessary part of the controller, and for the DataBinder that spring provides, it's completely usable, and the only thing that's bad is if an object has an inline object, such as a customer object inside the order object, Spring requires you to create a customer object and assign it to an order object before you can implement a binding like order.customer.customer_no. I was lazy, and took Jakarta beanutils out myself made a binder.

3.5. Extract base class

Finally, we could not help but extract a base class, responsible for multiaction and some other simple methods. Sprnig's Multiactioncontroller did too dead, stipulating that the 1th of all functions, 2 parameters must be request and response, do not understand dynamic, gentle injection of parameters.

After simplification and simplification, it is already very simple a Java Bean, anyone can easily start, even if the tide of the technology of a certain month now all of the MVC framework is submerged, and not no one to maintain.