On 1/23/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Michael Jouravlev wrote: > > ;-) (Frank, any particular reason for not liking dispatching actions?) > > It's off-topic for this discussion I think, so I'll give you a quick > answer (as quick as I'm capable of at least!), and if you'd like to > discuss it more, feel free to eMail me or start a new thread somewhere... > > First, I should point out that I don't not use DispatchActions at all, > but I tend not to 95% of the time. Also, I have no solid *technical* > reason not to use them. It just doesn't quite *feel* right to me...
Maybe it doesn't feel right because using a dispatch action is effectively using an action as a controller, instead of using the controller as a controller? That's the main reason I don't like them, and _never_ use them. I also agree with most of what you say below. But since this is way off topic, I'll shut up now. ;-) -- Martin Cooper First, I prefer looking at 10 different classes with 10 lines of code a > piece than one with 100 lines of code. My brain has an easier time > following the smaller classes (sometimes at the price of it being harder > to see the whole). I find that it makes it easier for others to grasp > code when they are being exposed to it for the first time too (I suspect > this is just a psychological thing... they feel more confident in their > ability to comprehend 10 lines of code than 100, something like that). > > In addition, I think it makes working in teams a little easier... this > tends to be true any time you make things more granular. You can dole > out tasks in a more fine-grained way. > > I also think it makes unit testing easier, or at least more finely > focused. > > I think there is less chance of breaking something inadvertently when > you have to make a change with a regular Action than a DispatchAction > (although I admit I have no evidence to support this one at all!) > > Also, I prefer to think of a web application as a collection of loose, > independent and atomic services that can be requested individually to > form a coherent whole (even if those services are tightly related). > Having each individual function broken out in its own class jives with > that perception a little better. > > Lastly, I don't like the idea that I can't really guarantee what is > going to be executed. What I mean is that if I have a mapping that uses > a particular regular Action, I know for sure precisely what is going to > be executed if that URL is requested. With a DispathAction though, I > have no such guarantee because it's based on a parameter that could be > fudged. Leaves a little more room for hackery IMO. > > I don't mean to try and convince anyone by the way... I already know I'm > in the minority :) > > Oh geez, I really *can't* give a brief answer, can I?!? > > > Michael > > Frank > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
