What goes into Action (and what doesn t)

What goes into Action (and what doesn ‚ t)

Don ‚ t even think twice ‚ Action classes should contain only the presentation logic. If it is business logic it does not belong here. What qualifies as presentation logic? The following do ‚ analyzing request parameters and creating data transfer objects (for server side processing), invoking business logic (preferably through business delegates), creating view-models ‚ the model JavaBeans for the JSPs, selecting the next view and converting exceptions into appropriate action errors. That ‚ s probably it.

The common mistake while coding the Action is stuffing the execute() with a lot of things that don ‚ t belong there. By the time it is noticed, the execute() method has intermingled request handling and business logic beyond the point of separation without considerable effort. The separation is tough because, when there is no architectural separation, the HttpServletRequest and HttpSession attributes will be used all over the place and hence the code cannot be moved enmasse to the server side to ‚“ extract a class ‚½. The first resolution you have to make for a cleaner and better design is to avoid this temptation .

A preferred way of splitting the code in Action ‚ s execute() method (or rather MybankBaseAction ‚ s process() method is by layering. The functionality in process() method can be divided into three distinctive steps.

1. User Action Identification

2. Transfer Object Assembly

3. Business Logic invocation using Business Delegates

The postprocess() method is suitable for forwarding the user to the chosen view based on the output from business tier . Let us start looking in detail at the above three steps in process() .

User Action Identification : The first step in process() is to check what action the user performed. You don ‚ t have to do this if DispatchAction or LookupDispatchAction is used. The framework itself calls the appropriate method.

 if (user pressed save button) {             //Do something     } else if (user pressed delete button) {             //Do something else     } 

Transfer Object Assembly : The next step is creating serializable data transfer objects (DTO) that are independent of the HttpServletRequest and HttpServletResponse (and the entire javax.servlet.http package). This involves copying the ActionForm attributes into a regular serializable JavaBeans. The formal term used to describe this copying process is Transfer Object Assembly. The class that assembles the transfer object is called Transfer Object Assembler. Every tier uses object assemblers when transferring objects across the tier boundary. In general, the object assemblers used to send data from business tier to presentation tier have some intelligence. However the object assemblers used to send data from presentation tier to business tier are straightforward. They are monotonous and dumb (It better be dumb. Otherwise you are coding business logic here). You can take advantage of their straightforward nature and easily develop a framework using Java Reflection API to perform the object assembly. The framework thus developed takes the ActionForm-to-DTO mapping information in a XML file and creates the DTOs.

To make life a bit easier, you can offload some of the conversions to the BeanUtils class in Commons BeanUtils. This jar is packaged along with Struts. You can use the BeanUtils.copyProperties(dest, orig) method to copy the properties with same names between the form bean and the DTO. It also does the required data type conversions in the process.

Business Logic Invocation : The DTOs thus created are transferred to the business tier as arguments while invoking the busiess logic methods . Consider how a Loan Session EJB containing the business logic for loan management is invoked using the standard Service Locator pattern. Service Locator is a core J2EE pattern that is used widely to locate the business service ‚ in this case used to locate the EJB.

 LoanMgmt loanmgmt = (LoanMgmt)                ServiceLocator.getInstance().lookup(LoanMgmtEJB); 

The above method call can throw RemoteException , CreateException . If the same business service is implemented using CORBA, a different Exception might be thrown. At times you will certainly have a lethal combination of EJB and mainframe serving as the business tier. Whatever be the case, you should isolate the web tier from these dependencies that are a direct result of the choice of implementation for the business logic tier. This is exactly where the Business Delegate comes in.

The Business Delegate is another Core J2EE Pattern and decouples the web tier from dependencies on the choice of business logic implementation. Typically business delegate is a class with implementation for all the business methods. Figure 4.3 shows the Business Delegate class. The client invokes the methods on business delegate. The delegate, true to its name delegates the client calls to the actual implementation. It uses the ServiceLocator to lookup the Service, invoke methods on it and convert the implementation exceptions into application exceptions thus reducing coupling.

Figure 4.3: Business Delegate.