I've MOSTLY fell on the side of the one Action per use case way of thinking. There have been instances where I did the multiple functions in a single Action, but generally not.
One production app I did here has something on the order of 400 Actions. Kind of a lot I think :) I'm not sure if it makes it easier or harder on people to wrap their brains around, especially upon first exposure, but I think isolating the pieces of a system as much as possible is better in keeping with the whole idea of loose coupling. This is along those lines. Certainly makes it easier to farm out work to underlings this way. I find the bigger debate, which there was a thread about a day or two ago, is how you actually package it... Do you just have a single package for all your actions or do you sub-group the Actions into individual packages? Even with the 400 Action project, I like seeing them all in one package myself, but it's certainly a debatable point. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, September 21, 2004 2:49 pm, Felipe Victolla said: > > Hi, > > I want to know the opinion of the another developers of this list with > your > experience in modelling the struts Action classes. What's the ideal point > of > Action classes granularity? > > One approach is building one Action for each Use Case. Example: > NewUserAction, EditUserAction, ListUserAction (for dealing with creation, > listing and update of user data in an application). I like this approach > because of the direct mapping from the use case models to java classes. > Another approach is to build one class for each "operation": UserAction, > for > example. This action will be more complex than in the first approach, but > we > will have fewer action classes. > > What is your experience in this topic? Any other approaches for dealing > with > this? > > Thanks in advance, > Victolla > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
