I have a confession to make. I am a very lazy programmer. I *HATE* typing things more than once. And I particularly hate having to revisit code after I've written it - even if the underlying architecture has changed.
So I am vexed by my current implementation of the MVC abstraction. Right now, I have things set up like this: Actions handle the Control layer. ActionForms (and JSPs) handle the View layer. Pure Java proprietary classes handle the model/business logic layer. There's nothing rocket-sciency about it. My problem is that, in order to handle the model persistence, my proprietary classes have logical transaction methods like updateUserRecord or createNewProductOrder which take the various information (ultimately passed down via methods from the Form bean). And these transaction methods have a whole swack of parameters, userFirstName, productID, etc. So if my data specification ever changes - suppose I add "preferredLanguage" as a new field in my customer record - I have to go through all my transaction methods and add the new field as a parameter to all the appropriate business methods. Then I have to go to my UserForm bean and add the necessary member variable as well as the getters and setters to support my new field. Then I have to go to the various JSPs to add this new field to the input forms and profile display screens. Now certainly some of this is unavoidable. After all, you can't change the business logic without having to make *SOME* code changes higher up to implement it. But it's that middle transformation that really bugs me: all the transaction parameters at the model layer and all the getters and setters at the view layer. So I got to thinking. Why not implement the Form bean as a wrapper around the persistence class itself? I could implement a persistence class called UserRecord, which has getters and setters as well as logical operations (commitChanges, logon, createNewUser etc). Then my UserForm bean simply contains a private instantiation of UserRecord and passes all get and set calls through to the UserRecord child. In fact, might it even be possible to use reflection to automate the getters and setters on the UserForm class? (I don't know enough about reflection yet, but it sounds plausible.) Certainly there are going to be some logical business tier operations that involve multiple record classes etc, so this doesn't work for all of my business logic. But it stands to reason that all of my business logic WILL be written around my business tier pure Java classes, so I can construct calls to those methods simply by passing the direct business classes from within the form beans. Has anybody worked with this structure? Is it tragically flawed? (I apologize if I've just reinvented a very common wheel, but it's new to me. :-) Jefficus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
