Musings on MVC abstractions and bean transformation

[Jeff Smith <je...@centralscheduling.net>]

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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Musings on MVC abstractions and bean transformation

[Jeff Smith <je...@centralscheduling.net>]

> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Musings on MVC abstractions and bean transformation

[Rick Reumann <r...@reumann.net>]

On Tue, 11 Mar 2003 11:53:07 -0700
"Jeff Smith" <je...@centralscheduling.net> wrote:
 
> 
> 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.

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. 

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).

  
> 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.

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.

> 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.


-- 
Rick Reumann

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org