Bad use of an ActionForm?

[Pat Wallwork]

Hi,
I am experimenting with struts on one of my projects a little and not sure if I'm utilizing it properly yet. I have one page that has a lot of form fields that users can select from to perform a 'detailed search' of my database with. I find that since I'm validating their input in the ActionForm already it seems like a good place to setup the sql query too. So, if their input passes validation then the ActionForm puts together the sql query as a String and I then grab it from my Action class for further processing.
This seems the easiest approach to me so far, but I'm not sure that it's a good idea to be performing some of the business logic in the ActionForm. (I'm also not even sure if that would be considered business logic anyways!) Any thoughts would be much appreciated!
-Pat

[Bruno Arantes]

Hi, Pat.
I think the best way you can do that is to make the basic validation in the ActionForm and then perform the business logic in the Action. I also suggest you use a Data Access Object (DAO) to perform data-access operations like database queries, inserts, and so on...
Placing your data-access or other business-related logic in the ActionForm will couple your system to Struts, and that's not a good idea when you think about portability, scalabity, etc...
Regards.

[Pat Wallwork]

Bruno, thanks for the reply.
You point out something I was worried about which is coupling my application to struts (although I do sometimes wonder if that is a bad thing with a small to mid size application). Creating the logic in my Action class just seems to me to be creating some extra overhead as there are more method calls to access the users input parameters so that I can form my sql query...as opposed to doing it right in the ActionForm where I already have access to the input parameters.
I wonder if I'm the only one a little confused on this or if it's a common misconception...but I see advantages and disadvantages to both sides here.
-Pat

[Bruno Arantes]

Originally posted by Pat Wallwork:
Bruno, thanks for the reply.
Creating the logic in my Action class just seems to me to be creating some extra overhead as there are more method calls to access the users input parameters so that I can form my sql query...as opposed to doing it right in the ActionForm where I already have access to the input parameters.
I wonder if I'm the only one a little confused on this or if it's a common misconception...but I see advantages and disadvantages to both sides here.

Pat,
I think that we can build small- or even medium-sized web applications without worrying too much about framework coupling. But in these cases, we might think that we could even make thinks "simpler" (and maybe develop them quicker) by building queries in the JSP page itself, thus eliminating the need for an ActionForm...
My point of view is that one of the goals of a robust framework like Struts is to enforce layered and better designed applications. Sometimes, a small overhead is the price to pay for such better design, but I still think that the advantages of using a layered design exceed the disadvantages.
Best regards.

[Pat Wallwork]

Bruno,
I agree. Too many times I've taken what appears to be a shortcut in developing only to have it come back and bite me later when the project has grown. I guess it would be the same with this example. That's partly why I'm interested in struts as it kind of enforces the mvc approach. I'll stick to the approach you mentioned and I appreciate your insight
-Pat

[Junilu Lacar]

Originally posted by Bruno Arantes:
Placing your data-access or other business-related logic in the ActionForm will couple your system to Struts, and that's not a good idea when you think about portability, scalabity, etc...

Well, if you use the Struts framework components, then you are already coupled to it. What you want to do is to minimize the coupling and make sure that whatever coupling is there is at the right places. This is probably what you meant anyway.
As you indicated, the ActionForm would be a bad place for tying in your business logic. Methods should do one thing. The validate method should do just that.
Business logic should be loosely coupled to the Controller part of Struts: the Action. For simpler apps, the business logic can go in the Action itself. If you want to loosen the coupling and add one more layer or two, you'd probably have the Action delegate work to your "business classes" that encapsulate the business logic. The business class will then interface with your persistence class that access the DB.
I normally start out with simple business logic in the Action then refactor the logic out to a business class as needed.