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/
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.
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.