CODE EXCEPTIONS

There are some general design issues to remember when coding Action classes. Let’s take a look at them.

Keep scalability in mind. Your Actions should not hold onto scarce resources (e.g., a database connection) across requests. These types of resources should be released prior to forwarding control to the View component. It is good practice to have finally clauses that do these resource releases just in case your Model Bean throws an exception.

Finally clauses are used as part of try/catch blocks. A finally clause is always executed regardless of whether you execute your try or catch block code. It is good coding practice to use finally clauses so that you don’t accidentally leave resources, like database connections or files open.

// If not valid, save a new token and forward appropriately

saveToken(request);

return mapping.findForward(Globals.FORWARD_INSERT);

Try to refrain from Action class bloat. Keep your Actions as thin as possible by keeping your business logic in separate Beans. Once you start embedding business logic in your Action, it will continue to grow (sort of like what happens when you try to eat only one Oreo cookie). Once logic is embedded in the Action class, it becomes harder to understand and maintain—not to mention the fact that your code reuse is going down the tubes.

Remember not to use instance variables in your Actions. If you get the impression that I’m trying to bang this phrase into your head, you are correct. It’s fine to have several local methods as long as any properties needed are passed in the method signatures. The JVM handles such properties using the stack, and so they are thread-safe.

Try to avoid having to write custom Action classes. Using an approach where there is a set of standard Actions that can act upon a known object type or interface drastically reduces the number of custom Actions that must be written. A parameter containing the type of Bean you should create can be passed to the standard Action using the parameter property in the Action configuration. For example,

Following this approach makes it possible to write applications that hardly use any custom Actions and allows for thebusiness logic to reside in the business Bean where it belongs.

Another practice worth mentioning, however obvious this might be, is how to name your Action classes. I always find it best to name Actions by what they do rather than by what mapping calls them. The reason for this is simple. If you name your Action class by its purpose, then you can reuse Actions in different mappings. So when you get up to writing complex applications that have lots and lots of Actions, your Action names will not be confusing to other developers. Examples of this are InsertAction, LogonAction, LogoffAction, etc.

Reference : Morgan Kaufmann