> Do you mean you are passing the actual fields into methods? Why not just > pass an object (data transfer object) that represents your customer into > the methods? ie.... updateCustomer( CustomerDTO customer ). All you > methods would stay the same if any changes occurred.
Yes, until now I've been passing fields. Not because I'm a masochist or an idiot, but as a way to limit the number of concepts I had to absorb while I was learning struts. I'm still in the "experimental learning" stage and have not yet committed any of these inefficiencies to a real app. Now that I've absorbed a sufficient amount, I am exploring the next step in best-practices coding - including getting rid of those lame field-littered methods. A DTO is essentially what I was proposing. But if I understand your use of the term properly, you view it as a "worker bee" class that is used pretty much exclusively to transform the data between the different layers. My proposed solution was to embody this functionality within the persistence class itself. The advantage is that I only have one class (instead of two) to change if/when my structures evolve. But my spidey-sense is tingling and I suspect there might be monsters under that particular bed - so I'm asking the wiser and more experienced to feed back on the idea. > > There is even Object Relational Mapping stuff that I haven't looked into > where you can map your objects fields to database columns. We're stuck > using JDBC here and even with that, I had one time wrote a class that > does use reflection and can call the right setters and getters to set > PreparedStatements, or going the other way, will take ResultSet fields > and populate your bean. (Only trick was you had to make sure that you > named the columns for your query the same bean field names). I haven't heard anything about this. Do you have any pointers to more info? > Using the DynaActionForm stuff this is a piece of cake. Just type the > name of the new field in the config.xml file. Later, then just use > BeanUtils.copyProperties to copy all of your DynaActionForm beans > properties to the DTO you created. Using my proposed encapsulation of the persistence class within the form bean, this step should be unnecessary, as the form bean essentially redirects its own getter/setters to those of the encapsulated persistence class/DTO. > > > Then I have to go to the various JSPs to add this new field to the > > input forms and profile display screens. > > Well, not sure how to help there. I'm sure you could create a generic > tag if there isn't one already, that maybe strips fields out of your > form bean and makes input fields, etc. To me the view at this level is > so specialized there isn't much point in cutting corners with a dynamic > solution. I wasn't really looking for a dynamic solution to this. It was just part of the overall picture of all the places where changes to the db had to be replicated/retyped. I agree that this context is way to amorphous for any useful generalized solution to be worth investigating. Jefficus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
