Using action classes as adapters and session EJBs for business logic sounds like a good way to go. Is also using EJBs as actionforms is a good idea because they are a good target for object reuse/

Ted Husted

ActionForms are not designed for reuse with an EJB. In fact, early on, the ActionForm was changed from an interface to an abstract class to discourage this idea.

The reasoning goes like this:

  • An ActionForm is part of the view layer of MVC, not the model layer like an EJB (or a regular JavaBean that represents persistent data).
  • The sole purpose of an ActionForm is to maintain the state of all the input variables on a particular form, so that you can reproduce the form pre-filled-in if the user made an error that they need to fix. This matches the expectations of users who are used to GUI-based client server apps, that never make you retype any input except the stuff you did wrong.
  • Because of the above, the "domain" of an ActionForm does not necessarily match any existing EJBs or model layer JavaBeans. It is not uncommon to have inputs from a single form that will ultimately cause updates to more than one undelrying EJB or model bean.
  • Using a separate class for the ActionForm means you can change the underlying organization of your model beans or EJBs without impacting the view layer (although there might be modest impacts on the Action classes that copy things back and forth).
  • In addition, most EJBs and model beans have validation rules internally that prevent them from accepting semantically invalid data. Such rules would prevent you from accomplishing the primary purpose of an ActionForm -- storing all of the user's input fields, so that you can reproduce the input screen.
  • Also, if your form is multiple pages and you were using the real EJB, let's say you start updating properties based on receiving the first page. Now, you've potentially started locking resources in the underlying database -- and you have to deal with the fact that the user may never come back and finish this transaction.

So, the bottom line recommendation is that you plan on building simple JavaBeans for your ActionForms. Most of the time, an ActionForm will have just getters and setters, with no error checking (other than a validate() method if you want to use it, plus the reset() method). PropertyUtils also has a convenience function that can copy properties with like names from your EJB to the ActionForm bean (or vice versa), to reduce the amount of tedious code that this approach implies. And, at some future point, it's reasonable to expect a development tool to be able to auto-generate ActionForm beans for you.

Using an EJB as a bean that provides data values used in the presentation, on the other hand, is pretty easy. Just store the client-side instance you get back from the EJB server as a request attribute or session attribute -- from the perspective of the Struts custom tags, this EJB just looks like a JavaBean with getter methods, so they don't care that it is really an EJB. NOTE: If the EJBs are really on a remote server this could have some performance impact -- you might be better served to copy data into local beans in that case.