I'm curious as to what the struts community opinion on this practice is. I'm working on a project which has a huge action class. Essentially, it looks at a button request value, which is different for various links on the page, and does a 6 block if/else lookup. Is this a recommended practice. It's a large class mainly because the business logic is contained in the actions, but I was wondering if it would also be valuable to break up the if/else conditional into separate classes. The argument i'm getting is get the business logic out first, and the if/else lookup won't be very big, so one action class is better. So I guess the question is , what is the view on passing a submit button value to the single action, and acting depending on the type of submit?
. . .in most cases, an Action object should invoke another object, usually a JavaBean, to perform the actual business logic. This lets the Action focus on error handling and control flow, rather than business logic.
I agree about the business logic. I am moving everything out into a model now, but am getting resistance to separating out multiple actions. I was just wondering how others in the community view multiple actions vs. a single action with a large if/else block. Thanks for the reply. Looking forward to even more opinions please!
Sounds like you might want to look at using multiple action methods within your action.
Step one (already mentioned up-thread): get the business logic out of the action
Step two: look at the else-if logic tree remaining and decide which of the three approaches below makes the most sense for your app and "philosophy" a) Many small, non-related actions b) Many small, inheritance related actions with shared behavior c) Single action with multiple methods honoring the execute contract (aka a more "dispatch" action inspired approach)
My guess from your description of the problem would be that either b or c would be a good match. To me both b and c are often "correct" and equally good... the choice between them is normally a more personal opinion...
Joined: Jan 31, 2008
Bear, I tried to use that approach, it seemed to not work so well. Apparently , OO isn't quite used here other than the fact they say they use java. Hence the massive use of large static classes.
Eric, I was trying to convince them that option B would probably be the way I would go, since there is definitely duplicated logic in each block. I also mentioned option C, but they had never heard of a dispatch action, and said they didn't want to introduce "new" technologies.
I didn't think I was so far off on my thinking to correctly refactor the code.
Thanks for everyone replying. Maybe i'll print out the thread and show it to the managers
As always, I welcome more thoughts on this issue. If there are valid points for the current way it's being done, speaking strictly from an action perspective and not the business logic in the action, I would love to hear them.