It may seem like a long way around for some, but the pattern I have been applying is to keep the ActionForm classes as presentation objects, have "data model" classes that represent the fields in the database for persistence, and between these, have value objects that represent the true "object model" with which you want to operate. Mixing these three concepts together is, IMO, what generally gets one into problems related to incomplete separation between layers.
As for responsibilities, I introduce a business delegate between the Action and the persistence in which the actual "work" -- the use cases/user stories implemented by your system -- is performed. The responsibility of the Action is to translate between the presentation objects (ActionForms) and the value objects used by the delegate. The value objects are representative of the object model of your application. The persistence layer, implemented by EJBs and/or DAOs, converts between the application object model represented by the value objects and the persistence model represented by classes that are closely related in structure to your database tables. As I said before, this may seem like overkill to some. And it might really be overkill depending on your application and its requirements. But I think that this pattern serves to keep the layers of your model decoupled according to a logical separation of concerns. It represents, I think, a focus on the business layer being the true heart of the system with the presentation and persistence layers there to support it. And since the persistence layer is encapsulated from the business and presentation layers, you can choose to change out your persistence layer or mingle technologies as you see fit. If you'd like to see more, you might visit the J2EE patterns catalog here: http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/ This material has subsequently been refined and published in the Core J2EE Patterns book: http://www.bookpool.com/.x/t4tyn2dfrn/sm/0130648841 Best regards, Jim Cakalic > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 26, 2002 10:51 AM > To: [EMAIL PROTECTED] > Subject: DB Access from Struts > > > Hello, > > A general practices question about db access using standard > java or EJB with struts. What is the best approach for > pluging db access into the struts framework in each case? For > example, if I'm using torque to generate all the DB access > classes, should I still use the Form Bean classes or its > better to simply have the torque classes extend the > ActionForm interface? Or is it better to access the torque > classes in the Action class? And what about EJB? > > Thanks, any help is much appreciated. > > Bilal > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >
