Re: Action Granularity
Frank, On Tue, 21 Sep 2004 15:03:32 -0400 (EDT), Frank W. Zammetti (MLists) <[EMAIL PROTECTED]> wrote: > 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. i was following that thread. i'm surprised it didn't carry. i was curious to see how it played out as well. i'm currently packaging via functionality. so: com.company.project.inventory.action com.company.project.inventory.forms etc. but at the moment i'm just trying to convert this app over to Struts and i'm working on one functional area at a time. once i get one completed we'll re-evalute and determine if the rest of the team will join in and Strutify the rest of the app. i currently have four packages within my functional package. rough guess there are about 10 functional areas in the app. (User, Customer, Inventory...) if i was building this app from scratch using Struts i'm not sure if i would have packaged it the same way. but this method works well for adaption. andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Granularity
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]
Re: Action Granularity
Hi, i'm pretty new to the Struts arena, but since you're looking for general info i can lend my .02. ;) On Tue, 21 Sep 2004 15:49:34 -0300, Felipe Victolla <[EMAIL PROTECTED]> wrote: > > 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. > i have been going with the first approach you mentioned. to create a separate action for each use case. you do end up with quite a few action classes following this approach (depending on your application). but they are always simple classes and easy to work with. i think (hope) this will make maintenance easier in the future. i think i've only come across a couple posts that have mentioned it is ok to put multiple actions in one class. but these are usually related actions (i.e. CRUD - create, read, update, delete) or actions that have a lot of functionality in common. but i don't really think there is a 'right' way or 'wrong' way. HTH, andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
