• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Struts - Separation of Control and Model

 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've recently started working on my first Struts application and I seem to run into a similar problem fairly often.

A given Action class is responsible for gathering information from the framework (form bean/session/etc.) and formatting that in a way so that the model can process the request without knowing it is part of a web application. Perhaps my concept of what an Action class should be doing is incorrect but that, in my mind, is one of the tasks it should perform.

The Model then processes that request and, optionally, returns data to the Action class. It does all of this with no knowledge that it is part of a web application. That, of course, increases the chance that your business components can be re-used in another application.

My trouble really seems to be with the interaction of these two layers. Often, I find that my Action class needs to pull multiple fields from the Form Bean and pass them to the model. In cases in which I need to pass a large number of parameters to the model, it might be easier to pass a single object, rather than a whole slew of individual parameters.

Similarly, when the model has completed processing the request, it will need to return some data to the Action class. If there is more than one piece of data being returned (which seems to almost always be the case), you'll want to return an object (either via return or In/Out parameter) to the Action class.

One solution I've seen used around the office is to simply pass the entire form bean to the model. The model can grab the data it needs from the form bean and then populate additional fields in the form bean with the data it needs to return. While this is easy, it seems like it violates some basic principles. Namely, it makes your business logic less reusable in a couple ways. First of all, it now contains web application information, making it more difficult to use outside of a web application (i.e. a Desktop GUI app). Secondly, your business logic is now, more or less, dependent upon Struts. If you decide to go with another framework (a home-grown one, perhaps), your business logic would have to change.

Based on that, I'd really rather not pass the form bean to my model layer. I'd rather take the extra effort in my Action class to pull the data from the form bean and give it to the model and take the return data from the model and put it in my form bean. The problem I have with this is that we now need brand new objects to pass to the model and get back from the model. These objects are probably either identical (or awfulyl similar) to the form bean. It just seems silly to me to have multiple classes that are so similar in an application. If nothing else, it increases confusion as far as what each class is for.

So, is there a good approach to separating your business logic from your web application? It's something I've been struggling with for some time now and I just never seem to able to nail down a real nice solution.

Thanks.
 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In cases in which I need to pass a large number of parameters to the model, it might be easier to pass a single object, rather than a whole slew of individual parameters.


You're right.
Transfer Objects

These objects are probably either identical (or awfulyl similar) to the form bean. It just seems silly to me to have multiple classes that are so similar in an application.


This often is the case that they are similar. The Transfer Object, though, will hold only the raw data (it's a tad smaller) and may be structured differently than the ActionForm.

Besides, would it not seem equally silly for the backend to create Struts ActionForms?

Also, you could end up in trouble sending the ActionForm because you would be handing off an object that the frontend might not be done with yet. For instance, if your ActionForms are session scope you could end up accidentally calling the reset method on it before the backend processes it (a double-submission could cause this).

I admit that I sometimes put the Transfer Objects directly into the ActionForms so that the TO becomes a nested object.
For instance, a TO with a variable of shippingAddress makes:
<html:text property="name"/>
become:
<html:text property="shippingAddress.name"/>
Many times this makes sense when the Transfer Object's data [coincidentally] has a structure already similar to a specific GUI page.
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marc Peabody:

This often is the case that they are similar. The Transfer Object, though, will hold only the raw data (it's a tad smaller) and may be structured differently than the ActionForm.



What's the difference between the two, then, just the fact that the ActionForm may contain additional validation information?



I admit that I sometimes put the Transfer Objects directly into the ActionForms...



Do you mean that the Transfer Object becomes an inner class or is simply referenced from the Form Bean?
 
Marc Peabody
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What's the difference between the two, then, just the fact that the ActionForm may contain additional validation information?


Sometimes that and the reset method are the only difference. But remember, the TOs don't always match up with the GUI page.
For instance you could have a list of objects displayed in an html table and 6 textboxes above it that make up the inner values of the same kind of object (possibly with an "Add" button to add a new object to the collection). In this case you would have an ActionForm with 6 variables that the TO does not need. The Action would (after validation) create a new object using the values submitted and add them to the list. The TO would only hold the list and not the six extra values.

I forgot to mention that if you changed frontend technologies, you could still keep your TOs whereas if you used all ActionForms you would end up in a bit of a bind.

Do you mean that the Transfer Object becomes an inner class or is simply referenced from the Form Bean?


Referenced, with its own accessor methods.
In my example, Struts would convert shippingAddress.name to:
getShippingAddress().getName()
and
getShippingAddress().setName()
Where getStreetAddress is a method on the ActionForm that returns the TO and the get/setName() are accessors within the TO itself.
[ December 15, 2004: Message edited by: Marc Peabody ]
 
Marc Peabody
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another Thread

Here is yet another good reason why the ActionForm and TO should exist separately. There are times when the ActionForm is best having a String type for a certain value while the TO should hold an Integer.
 
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(A disclaimer first - I know very little about frameworks, so take what I say with a grain of salt)


These objects are probably either identical (or awfulyl similar) to the form bean. It just seems silly to me to have multiple classes that are so similar in an application.


I found that to be a real turn off too.
If you have a choice, you may want to look at other MVC frameworks, I believe Spring MVC can bind request parameters directly into your model objects.

To compare various frameworks, you can check out Matt Riable's appfuse .

And if you must go with struts,
xdoclet for struts can ease the pain a little bit.
[ December 17, 2004: Message edited by: Sonny Gill ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic