Re: Editing a database record best practice?
OTT, as in amazing dull to code up yet another value object... I've got value objects coming out of my ears :) Jonathan Message History From: Adam Hardy [EMAIL PROTECTED] on 12/02/2002 09:49 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Editing a database record best practice? On Tue, 12 February 2002, Jonathan Gibbons wrote: I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. OTT as in the case of an app which you know you're going to deploy on a webfarm? In which case the DB will probably be on a seperate server, the webservers on another, possibly with EJB on board, possibly EJBs on their own server? The technical issue is whether you can realistically pass a form object from a performance point of view from one server to another. Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Editing a database record best practice?
Sadly, the web tier has special requirements for value objects that most (reasonable) value objects cannot meet. http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19338.html http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html But ActionForms should not be passed up to the business tier, except like any other JavaBean that can be mined through reflection. The general approach is to transfer the data from the ActionForm into a standard value object, that could, for example, be used in a remote call. Of course, this is just for data collection. For data presentation, any old value object you already have should work just fine. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Jonathan Gibbons wrote: OTT, as in amazing dull to code up yet another value object... I've got value objects coming out of my ears :) Jonathan Message History From: Adam Hardy [EMAIL PROTECTED] on 12/02/2002 09:49 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Editing a database record best practice? On Tue, 12 February 2002, Jonathan Gibbons wrote: I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. OTT as in the case of an app which you know you're going to deploy on a webfarm? In which case the DB will probably be on a seperate server, the webservers on another, possibly with EJB on board, possibly EJBs on their own server? The technical issue is whether you can realistically pass a form object from a performance point of view from one server to another. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Editing a database record best practice?
EJBs have their uses and sometimes are required (JMS, for example). Further, an EJB (especially a session bean) is no slower than any other Java entity accessing a database (which has more to do with network latency, and database performance than EJB technology) and provides great separation of the view from the model, plus, with the latest efficiencies in JVM and container technology there is no performance hit for using EJBs in and of themselves. All things being equal, performance, as has always been the case, is mainly determined by the code. Finally, where in the world did you get the idea that Sun has a hardware stake in promoting EJBs? That took a great leap of imagination! Cheers! Mark P.S. .Net is great technology. Do not let the typically fanatical pro-Java/anti-Microsoft bias blind you to the possibilities. Java 1.1 already runs in it, C# is a great combination of the best of C and Java 2.0, and someone is bound to develop a compatible Java 2.0 byte compiler for the framework within a year (rumor is IBM is already doing it). My guess is that .Net will encompass Unix as well in a fairly short period of time and the world of Net application development will be split between EJB and .Net developers. Try before you cry: http://www.mail-archive.com/struts-user%40jakarta.apache.org/ -Original Message- Sent: Tuesday, February 12, 2002 6:25 PM From: Vic Cekvenich [EMAIL PROTECTED] === Oh, and... avoid EJB (it tends to be overused by newer developers, and is slow to develop and slow performance. Sun's way of selling hardware, but when projects fail, manager makes you go to : MS .NET ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Editing a database record best practice?
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]
Re: Editing a database record best practice?
Hi, I've been thinking about this and have just arrived at the point you left behind! OK, the issue is that there is a data layer that holds EVERYTHING. And its all normalised inside databases and is pretty hard to utilise within your business code. So we create a business layer which loads up rows and parts of rows to perform the logical updates and operations required. We use EJB, CMP, OR, JDO whatever. We then have a presentation layer that is user oriented, mixing language varient information, multi-table information, business calculation information, security and so on. Each page/screen only holds the information needed and it holds it in a user friendly form (say Strings for ease, as in Struts). User-MiddleTier/business-database Network bandwidth and the marshalling times are an issue (maybe). Lets say we are using EJB, local interfaces from mid tier to DB, so its as quick as currently possible (ahem). Now the presentation data is held in strut form objects. I recon it is these that should be used as the data transport from mid to gui and back. It means we are only shipping the data we need. But we are putting presentation logic within the mid tier - ie objects that are purely there to populate data for a specific screen. I know this is fast and scalable. BUT, I also know that I have to stick struts.jar into the EJB container (usually they have an obvious common libs place - eg for jdbc drivers). Do we do this? A sacrifice of time against elegance. Hmmm. I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. Just answered myself, anyone else got a point of view? Jonathan ps With respect to the original thread, I don't hold any state info in the session because of scaleability, timeout, and state transition issues (back button, multiple browser windows etc). It does mean an update is read for display, and then read for validate/insert. But I recon the DB is there to be used. I do hold user info in the session, but not activity state. Message History From: stf [EMAIL PROTECTED] on 12/02/2002 17:31 CET Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: Editing a database record best practice? 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
Re: Editing a database record best practice?
On Tue, 12 February 2002, Jonathan Gibbons wrote: I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. OTT as in the case of an app which you know you're going to deploy on a webfarm? In which case the DB will probably be on a seperate server, the webservers on another, possibly with EJB on board, possibly EJBs on their own server? The technical issue is whether you can realistically pass a form object from a performance point of view from one server to another. Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Editing a database record best practice?
Is this really an issue?! if you pass a from object from server to server, it shouldn't be much more than the fields it contains - so it makes absolutely no difference how much code you have around your data - no matter in what structure you keep them (or do you mean that it is an issue of memory - as the Form-object will be recreated in the midle tier: along with everything needed only in the view-tier...) But if you do (as we do) the conversion from form to value-object and vice-versa in the Action: This way the Form never leaves the presentation-tier and the Value-Objects are as simple and dumb as they can be...: This works very well for simple EntityBeans, which we access directly from the Action, but it even works with more complex Value-Objects that finally work on several EntityBeans: We just facade them with a stateless-session-Bean, which sorts the values and drops them in the right EntityBeans. This even scales on clusters, as you can separate servlet/jsp, the ejb-container and the database on different machines... - Original Message - From: Adam Hardy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 6:49 PM Subject: Re: Editing a database record best practice? On Tue, 12 February 2002, Jonathan Gibbons wrote: I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. OTT as in the case of an app which you know you're going to deploy on a webfarm? In which case the DB will probably be on a seperate server, the webservers on another, possibly with EJB on board, possibly EJBs on their own server? The technical issue is whether you can realistically pass a form object from a performance point of view from one server to another. Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com -- 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]
Re: Editing a database record best practice?
Subject: Re: Editing a database record best practice? From: Vic Cekvenich [EMAIL PROTECTED] === Oh, and... avoid EJB (it tends to be overused by newer developers, and is slow to develop and slow performance. Sun's way of selling hardware, but when projects fail, manager makes you go to : MS .NET ) Ryan Cornia wrote: 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]
Re: Editing a database record best practice?
It means we are only shipping the data we need. But we are putting presentation logic within the mid tier - ie objects that are purely there to populate data for a specific screen. I would say that *what* is on the screen is a business requirement. Getting *what* we need for the screens runs up and down the business tier, and should be part of optimizing queries and indexes, et cetera. But *how* it is displayed is the presentation logic. The idea being you could do the same application as a Web app and a desktop app, and have the same data on each screen, but displayed very differently using different presentation markup. Also, Struts does not require finely-grained ActionForm beans, or any type of 1:1 relationship between forms and beans. You can easily have one form bean for the entire application, and just validate it differently depending on what ActionMapping uses it. If a property isn't used on a form, it's just a null, and can be ignored. But, yes, the best practice for editing a record is to get someone else to do it, and leave Struts out of it =:o) Jonathan Gibbons wrote: Hi, I've been thinking about this and have just arrived at the point you left behind! OK, the issue is that there is a data layer that holds EVERYTHING. And its all normalised inside databases and is pretty hard to utilise within your business code. So we create a business layer which loads up rows and parts of rows to perform the logical updates and operations required. We use EJB, CMP, OR, JDO whatever. We then have a presentation layer that is user oriented, mixing language varient information, multi-table information, business calculation information, security and so on. Each page/screen only holds the information needed and it holds it in a user friendly form (say Strings for ease, as in Struts). User-MiddleTier/business-database Network bandwidth and the marshalling times are an issue (maybe). Lets say we are using EJB, local interfaces from mid tier to DB, so its as quick as currently possible (ahem). Now the presentation data is held in strut form objects. I recon it is these that should be used as the data transport from mid to gui and back. It means we are only shipping the data we need. But we are putting presentation logic within the mid tier - ie objects that are purely there to populate data for a specific screen. I know this is fast and scalable. BUT, I also know that I have to stick struts.jar into the EJB container (usually they have an obvious common libs place - eg for jdbc drivers). Do we do this? A sacrifice of time against elegance. Hmmm. I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. Just answered myself, anyone else got a point of view? Jonathan ps With respect to the original thread, I don't hold any state info in the session because of scaleability, timeout, and state transition issues (back button, multiple browser windows etc). It does mean an update is read for display, and then read for validate/insert. But I recon the DB is there to be used. I do hold user info in the session, but not activity state. Message History From: stf [EMAIL PROTECTED] on 12/02/2002 17:31 CET Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: Editing a database record best practice? 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
