Martin, this question surely should be asked Wesley. Perhaps I didn't comment out the parts by Wes in my reply.
Have a nice weekend! Martin > -----Ursprüngliche Nachricht----- > Von: Martin Gainty [mailto:[EMAIL PROTECTED] > Gesendet: Samstag, 7. Oktober 2006 16:19 > An: Struts Users Mailing List; [EMAIL PROTECTED] > Betreff: Re: FRIDAY #1 JavaBeans/Model > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
