Why are you needing to use EJB? Presumably something distributed, and you do no want to use SOAP.
If you use EJB for persistence, I would implement Astral Clones Design Pattern like this: Extend FormBean, and add a property of RowSet (a JDBC interfaces implemented by CachedRowSet). Add geters and setters to and from RowSet, that then go to whatever, EJB in your case. Add the rest of the Astral Clones. You can then later replace call to EJB with JDBC/RowSet update() method. (Why not do JDBC calls right away? EJB might make you slow if this is a larger app.). Then in Action, ask your FormBeans to connect, retrieve, CRUD, validate , and disconnect. If you need to write something more complex in Action, then use helper/utility classes. /* :-D J2EE development is a bit like Masonic brotherhood. There are perceived secrets about how it is really developed. Ex: What are design guidelines and exhibits best practices for building distributed applications with the Java Enterprise Edition/ aka How should I change my application requirements in order to use message beans. */ Search google.com for Astral Clones or RowSet or whatever. Vic [EMAIL PROTECTED] wrote: >Hi all, > >after browsing the FAQ and searching the mailing list archive, >I have not yet found a 'premium way' to go for EJB business logic >integration into a Struts application. > >It's pretty clear that the EJB stuff should go into the action classes. >I also saw hints that it might be useful to add another layer between >the action classes and the entity/session beans in order to keep the >action classes small and independent from the underlying business logic >tier architecture. > >So the recommended architecture would be > >action class <-> ejb 'helper' class <-> EJB Session/Entity Bean > >which allows for e.g. replacing the EJB tier by direct JDBC >database access without having to modify the action classes. > >Is the presented view correct/recommendable, or have I probably missed >some important developments concerning the Struts<->EJB issue? >Besides selected threads of this mailing list, are there any >instructive resources/links regarding the topic? > >Regards, > >-- >Thomas Corte ><[EMAIL PROTECTED]> > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
