Design Pattern in struts2

1. Command pattern

Basic definition: encapsulate the command (request) into an object, separate the invoker responsibility from the executor responsibility, and delegate it to different objects.

What are the benefits of responsibility division?

There is a single responsibility. The higher the cohesion, the higher the possibility of reuse. Imagine what it would be if the waiter not only wants to cook but also to cook.

Why is it more advantageous to decouple invoker and consumer er?

The lower the coupling between classes, the higher the possibility of scalability. After decoupling, replacing a waiter will not affect the work of the cook.

What does it mean to encapsulate a request into an object?

In the remote control example, for example, if I have a request to turn on the light, there should be a lightoncommand object, and the light should have lightoffcommand

In a web application, I have an add user request, so there should be an addusercommand to process the request, or the struts name convention is adduseraction.

So how does struts use Command pattern?

Client: filterdispatcher Servlet

Invoker: actioninvocation

Command: Action (not a must in struts2)

Concretecommand: adduseraction

Else Er: serviceimpl (not a must, Depends how many logic you want to put into concretecommand)

Struts. When do you call setcommand ()?

You have defined action mapping in struts. in XML, when the web iner is started, the configurationmanager loads struts. XML. When the request comes over, the Struts framework will find the concretecommand/action corresponding to the configurationmanager according to the current URL,
Then this action will be set to actioninvocation

Is command interface required?

In struts1, there is an interface, and all actions must be implemented. However, in struts2, action can be any pojo, because during runtime, the configuration file (metadata) can be used to call a specific action or method) + Java reflection. The advantage of this new approach is that pojo
With no dependency on the framework, the test will be easier. The disadvantage is that there is no interface constraint. The method for calling an action depends entirely on the default value (such as execute) or the configuration in the configuration file. If the settings are not correct, you can only find errors during runtime.

Is it mandatory for the aggreger?

No, it depends on the thickness of your action. If you want to make the action light, you will usually use userservice. adduser () in the action to do things. At this time, userservice is the volume er. It is also possible to put the logic of adduser in the action directly by designing the thick point of action.

In struts2, the command concept is used, but it is not strictly implemented according to its classic model. Instead, some modifications are made. These modifications may seem a little contrary to the design principles, for example, if the action interface is canceled, isn't it an anti-pattern or a reverse Interface Programming? But think about it, do we really need this interface here? Through the configuration file + reflection, we can also inject different actions to actioninvocation at runtime. Interfaces increase the coupling between user implementation and framework, so such modifications are actually positive, although we have lost some of the benefits of interfaces as a contract.

2. interceptor Pattern

It means that this is a model. It is better to say that this is a combination of the idea of AOP and pipeline, but the implementation in struts2 is very delicate. I have to say that this should be promoted as a model.

AOP: the so-called AOP is preprocess and postprocess. In system applications, many aspects need to be faceted, such as log, authentication, Etc .... I have read some implementations, such as Java Dynamic, but they are not elegant enough.

Pipeline: Hierarchy refers to the hierarchy of complex problems. Each layer only processes a small part of the problem. The layer-7 Communication Model is a typical example.

Interceptor pattern not only layer the system, but also provides AOP processing. In addition, it also provides infinite scalability for users in Plug-In mode.

How should we implement it?

The interceptor call process is similar to a stack call, so it is natural to think of recursion. This not only avoids the hack like dynamic proxy, but also provides better scalability.

Take the class in struts as an example. The class diagram is as follows:

Call process:

Pseudo code:

Actioninvocation

Public result invoke () {If (interceptors. hasnext () {interceptor = interceptors. next (); Result = interceptor. intercept (this);} else {action.exe cute (); // if no more interceptor exists, stop recursion and call Action }}

Interceptorimpl

Public someinterceptor implements interceptor {public result intercept (actioninvocation) {// pre-processing // recursive call result = actioninvocation. Invoke (); // post-processing return result ;}}

More: http://www.cnblogs.com/west-link/archive/2011/06/22/2086591.html

Http://bosy.dailydev.org/2007/04/interceptor-design-pattern.html

Struts2 Architecture

Struts 2 Framework: http://viralpatel.net/blogs/introduction-to-struts-2-framework/