we are using a similar approach with ejb's, that produce value object's instead of database records: We have generic ValueObjects that are filled into the formBean using reflection (You can do something similar with result-sets using the meta-data: as long as you don't mind tying your bean-properties to the database-field names...): along with the data, a timestamp is transported inside the value-object: So only the ValueObject with the last timestamp can make an update on the ejb (with only some exceptions (CLOb/BLOB-fields which get specific update methods) we make global updates, we just set *all* values from the value-object into the ejb. Coming back from the form the process works the other way round: copying the values from the ActionForm into the valueObject and then passing it to the ejb for update...
This sounds like a lot of copying: We first had the ejb's producing ValueObjects that extended action-forms with all the fields needed in the form: we ended up with having to package the struts-libs with every EJB caused by this mixing of business-object and view-layer (resulting in a lot of classloading-hassle: Fortunately you sometimes get real errors for bad design-decisions..) - so we ended up with this generic ValueObjectLayer that clearly separates the view from the Business-objects. Instead of using ejb you can try jdo (e.g castor, or intelliBO) - I'm not really sure, wether the need for such a neutralizing layer vanishes with this, but I think they will give you at least some handy tools to write the Data-Access-layer without having to write the sql by yourself. greetings stf ----- Original Message ----- From: "Ryan Cornia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 12, 2002 2:56 AM Subject: Editing a database record best practice? > A common scenario I run into is having a web application where the user needs to edit a database record. > > The simplest approach I can find is this - > 1.) Load the db record into a bean. Copy the bean props. to the form for display. Put the dbbean in the session. > > 2.) Show the form, when the user presses "save", validate the form, make sure, if possible, that the form primary key fields are equal to the dbbean in the session primary fields. > > 3.) Have the dbbean do an update statement. In order to do this properly, the dbbean needs to have kept the original db values so they can be put in a where clause. This insures that we are changing the record exactly as we loaded it. If somone made a change before the page was submitted, the update would fail. > > Is that the best approach to accomodate a sort of "optomistic locking"? Are there any tools to autogenerate the dbbean objects? I was thinking of trying to do it with an xml schema and XSLT to transform the schema to java objects. Thoughts? > > Thanks, > Ryan > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
