Entity beans as add/edit record containers.

[Brian H.]

Hey again guys (and girls).

In my applications, entity beans are a great resource for
consolidating data, and facilitating output formatting.

Now in true OO fashion, we also use beans to set up records to be
added (passing the bean to BeanDAO.create()), as well as edited (first
reading a bean, then modifying, then BeanDAO.save()). So when adding
a Project, we would grab an empty Project bean, set some setters, and
pass it to the DAO to be saved.

Based on my last thread, I have decided that I am going to lazy load
the “getStaff()” method of my Projects bean, where the method returns
an array of Staff beans. This also means that I have a “setStaff()”
and possibly even a “addStaff()” helper function. Now if I were to
add a new Project to the system, in my application’s controller layer
(listener) it seems like the proper approach is to first instance a
project bean, then pick out all of the staff IDs selected (from the
HTML layer), have the staffDAO “read” those staff beans, and then
either use “setStaff()” or “addStaff()” of my Project bean to set up
the proper staff / project relationship, so when I finally “save” my
Project bean, the ProjectDAO saves the project to the DB and then sets
up the proper cross joins with the staff table.

Ok cool, but that is a lot of overhead, no? Fully instantiating staff
beans basically to only store their IDs so that the add/edit DAO
routine can get access to them. I guess an alternative approach is to
grab empty staff beans (as opposed to fully hydrated ones) and simply
set the ID in those beans, and use “addStaff()” or “setStaff()” on my
project bean with those “light” beans. A little less overhead.

What are you guys doing? When you have to pass a bean to a DAO, and
express a nested relationship (these staff are assigned to this
project) do you pass a bean (Project), composed of fully hydrated
child beans (staff) just so that the DAO can grab the IDs to set up
the cross join in the DB?

Sorry for the long rant. Still sort of thinking out loud here.

-Brian

[Sean Corfield]

These are exactly the sort of questions that led me to use an ORM
instead of trying to solve this myself :)

Sean

[Sean Corfield]

FWIW, a reasonable compromise is to have setStaffByID() and
addStaffBy() methods since all you're trafficking in are staff IDs -
that then hides how the representation is actually handled whilst
providing a convenient (and in this case performant) API...