struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Gainty" <>
Subject Re: FRIDAY #1 JavaBeans/Model
Date Sat, 07 Oct 2006 14:18:40 GMT
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?
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
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,
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 
----- Original Message ----- 
From: "Martin Kindler" <>
To: <>
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message