Yes, that's exactly what happens. I understand your approach, even like it! :)
I think what it comes down to is do you break things up in an object-oriented way or a functional way? It can be argued that done as you say, you are breaking it up based on objects, which mimics how we generally develop nowadays, so it makes sense. On the other hand, my approach indicates that all the classes in the actions package serve the same general functional purpose. I'm not sure either is more correct in any way than the other... I personally find it easier to work on a project when I don't have to flip between a large number of directories (or, in a related kind of way, a lot of classes). I'm kind of old-school in this regard... The more of a piece of code I have right in front of me in one place, the better. This is largely contrary to OOP ideals, and sometimes I have to fight myself to NOT do what feels natural after so many years :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, September 17, 2004 2:57 pm, Rick Reumann said: > Frank W. Zammetti (MLists) wrote the following on 9/17/2004 2:54 PM: > >> I personally use #3. > > <snip> > >> com.company.project >> | >> *---actionforms >> | >> *---actions >> | > > Won't you end up with a TON of Actions though in one package? > > EmployeeUpdateAction > EmployeeDeleteAction > EmployeeSearchSetUpAction > EmployeeSearchGetAction > FooBarInsertAction > FooBarDeleteAction > > I was thinking of breaking it up a bit so all the related Employee > actions would be in one package under Action and same thing with FooBar. > > > -- > Rick > > --------------------------------------------------------------------- > 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]
