Summary of the usage of actions in Business Processing

Actions can basically process all the things at the business logic layer.

Generally, our action inherits dispatchaction, which can contain many different methods.

If you want to add data, upload your data to the action and then call the method in the Manager to add the data.
If it is deleted, the ID you want to delete will be passed to action and then the method in manager will be called to delete it.

Action is not a related operation for storing data to persistence.
Instead, you can use an intermediate switch to call the corresponding Manager interface based on your business (this interface is used to process persistent operations)

In fact, the process of action is much simpler.

Actions can indeed process simple data,

However, it is not suitable for processing large amounts of data that requires complex logic processing. Therefore, it is better to reduce the function of action.

If the action is only responsible for page Jump and Dao calling, the role of aciton is more obvious,ProgramLevel is clearer

the principle is the Java event model, event information is encapsulated in an event object. All event objects are derived from Java. util. eventobject. Each event type has a subclass, such as actionevent and javaswevent. Different event sources can generate different types of events. For example, a button can send an actionevent object, while a window can send an receivwevent object. The event processing mechanism in AWT is as follows:
* a listener object, A class instance that implements a special listener interface
* an event source is an object that can register listeners and send event objects for them
* when an event occurs, the event SOURCE sends the event object to all registered listeners.
* The Listener object uses the information in the event object to determine the response to the event

for example, there is a jbutton
first, you must register it for listening
button. addactionlistener (listener);
now, the listener object will be notified as long as an "Action event" is generated in the button, the preceding Code requires that the class to which the listener object belongs must implement an appropriate interface (here the actionlistener interface is used ). Like all interfaces in Java, implementing interfaces means providing methods in interfaces. To implement the actionlistener interface, the listener class must implement an actionreceivmed method. Its parameter is an actionevent object. For example, you can define it as follows:
class testlistener implements actionlistener {
.............
Public void actionreceivmed (actionevent event) {
// process the event
}< BR >}< br> the listener is constructed, you only need to generate a testlistener instance on it, and the listener can be used. The general processing can write this together with your main class, for example:
Import Java. AWT. event. *;
Import javax. swing. *;
public class test implements actionlistener {
private jbutton button = new jbutton ("OK");
Public test () {
button. addactionlistener (this);
}< br> Public void actionreceivmed (actionevent AE) {
// do work
}< BR >}< br> however, in many cases, internal classes are written.

It is not absolute to not process the business in the action. It depends on your project architecture,

If your architecture only has action --> Dao at the business layer, you need to process some services in action,

Of course, you can construct an action --> JavaBean/EJB --> Dao, so the business can be processed in bean.

If you construct the architecture into action --> service --> Dao, you will naturally process your business in the service.

The architecture depends on you. Of course, it depends on you if you do not process the business in the action. This is not absolute.