Good Morning Martin- I would say you're definitely on the right track and would inquire th reasons for combiinge 2 tables into one bean
If the DB is designed so that someone built table1 and for some reason built table2 which is basically an extension of the attributes for table1 then your bean should include both tables But this begs the question why split like minded attributes into 2 tables when you should denormalise them both into 1 for architectural, performance and functional reasons If the functional characteristics of the 2 tables are not related I would suggest using 2 separate beans Anyone else? Martin-- Information in this message, including attachments, is intended only for the confidential use of the recipient(s) named above. This message may be an Attorney-Client communication and as such is privileged and confidential. If you are not an intended recipient of this message, or an agent responsible for delivering it to an intended recipient , you are hereby notified that you have received this message in error, that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately, delete the message, and return any hard copy print-outs. This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its conte ----- Original Message ----- From: "Martin Kindler" <[EMAIL PROTECTED]> To: <user@struts.apache.org> Sent: Friday, October 06, 2006 10:43 AM Subject: AW: FRIDAY #1 JavaBeans/Model > First, I am going to design a database, then build a bunch of > beans that > more or less represent the data in the database by going > mostly one bean > for each table. There will likely be a few cases where one bean will > represent two tables (1:n relationship, where the attributes in the > 'many' table come as an array of objects when the getter is > called). The > persistence will happen as a method of each bean. Then, I'll > build forms > around the navigation of the site, and have a separate layer > or objects > that will build and persist the beans from above. > > Am I on the right track? > If you do this, I do not see a separation of the persistency layer from the model layer. But depending on the complexity of your business model this may be fine. I have done the following in my last project (I would not say that it is a perfect solution, but has proven to be easily adaptable to changes): in the persistency layer all DB specific information is encapsulated. It mainly consists of (approximately) one class per table with the CRUD-methods. This layer communicates with simple beans used as data transfer objects with the model layer. In the model layer I have my business objects (in my case there is about one model class for each bean class, but this need not be the case). These business objects have all the functionality needed in the business model (which is much more than just the data). These business objects are used in Struts actions modelling the work flow. The actions - being the "controller" layer - take user input from action forms to create/manipulate the model objects or vice versa take the business objects to create some "view" objects to be presented to the user. These are passed either in action forms or as request/session attributes to the JSPs building the presentation layer. Hope this gives you an impression how you could design your application. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
