Simplified spring (3)-controller Layer

Skip this article for fans of struts and webwork.

Does MVC separate M, V, and C? The simplest approach is that Two JSPs are responsible for the view, one is responsible for the Controller, and the other is responsible for the model Java Bean, which can already work well. At that time, everything was very simple.
Now, for some non-essential functions, so many non-standard Web frameworks are depressing. It is as simple as Ruby on Rails for development and can be used without many restrictions. For exampleWebwork
This type can also be considered. However, the more you use a framework like struts, the more troublesome it is, or there is a serious autistic tendency like tapestry. If you stick to the "special toys for experts", it is irresponsible to use them in the team.

So, My MVC solution is to use the Controller Interface of spring MVC to write the most common JavaBean as the Controller
In essence, it is similar to using JSP as controller in the past, but it has the characteristics of Spring IoC. The reason why such negative selection criteria are used is that the MVC framework of this generation is far from returning to the rad era, and it is doomed to be a short and transitional technology, it is not worthwhile to invest too much energy and team learning costs. 1. Principle

Spring MVC belongs to the static configuration front in Martin flower's "enterprise application model" based on plant species
Controler, uses dispatchservlet to intercept all *. Do requests, according to the configuration of the XML file, call the corresponding command object
Handlerequest (request, response) function, and inject dependent objects at the same time.
Our controller layer is a general JavaBean that implements the handlerequest (request, response) function.
2. Advantages

Advantages of spring MVC compared with Struts:
First, its controller has a loose to tight class hierarchy. You can choose to implement an interface with only one handlerequest () function, or use the simpleformcontroller class with many callback functions. Second, there is no need for form beans, or the so-called object-oriented page objects of tapestry. For those who are afraid of class expansion, it is best to change one thing and want to change to another place. Third, you do not need to emphasize xml configuration files. Declarative Programming is good, but if it is forced into a framework, everything should be declared in XML, Which is cumbersome to write, when reading the code, you need to configure the code on both sides to understand the problem. What about webwork? I have never tried it in practice, but I don't need much for the MVC framework.
The Controller of MVC can already meet the requirements, so we don't need to work out a set of webwork to set a hurdle for the team, as well as the trouble for upgrading versions between spring and WW2.
. Spring MVC has few source code and is easy to control and expand.
3. Simplification 3.1. directly implement controller to implement the handlerequest () functionFirst of all, simple form controller is not as good as mine. It is not simple at all. So sometimes I will directly implement
Controller Interface. The only function of this interface is for front
Handlerequest (request, response) called by the Controller ).
If you need an application object, for example, to use application. getrealpath (), you need extends webapplicationobjectsupport.

. Each controler is responsible for a group of related actions
I firmly support one controler responsible for multiple actions. One controler and one action are as boring as one function and one class. So I use
The most traditional method is to use URL parameters such as MSG = "insert" to give a group of related actions to a controler. Ror and groovy on
Rails adopts this mode, and spring also supports multiactioncontroller.
All of the above are functions that directly reflect URL parameters as controllers, while stripes
You can use annotation to mark the ing between URL actions and response functions.
3.3.xml Declarative Programming
My trade-off is very simple. Spring does not have any force. I only need to dynamically inject things in XML when it is necessary to change something without re-compiling. JSP paths are all taken back to the Controller.3.4.data BinderData
The binder is an essential part of the controller. For the databinder provided by spring, it is fully available. The only unpleasant thing is that if an object has an embedded object, such as an order object
It contains the customer object. Spring requires you to create a customer object and assign it to the order object.
Binding such as order. Customer. customer_no. I was lazy and took Jakarta beanutils out and made a binder myself.

3.5. Extract base classesFinally, I couldn't help extracting a base class, responsible for multiaction and other simple methods. Sprnig's multiactioncontroller is too dead. It requires that the first and second parameters of all functions must be request and response. It does not understand dynamic parameters and is gentle in parameter injection.

After simplification and simplification, it is already a very simple Java Bean. Anyone can easily get started with it. Even if the tide of technology in a certain month has overwhelmed all MVC frameworks, and no one knows how to maintain it.