Hey Ryan, > EventBroadcaster class -- wouldn't it just be easier to skip the > EventBroadcaster and invoke methods on the Controller directly? I'm > totally open to more levels of abstraction as long as they provide a > real benefit, but I think I'm missing something on this one.
The command pattern arises as a natural refactoring from the architecture you suggest -- it's what we'd call the "fat controller". You can place methods directly on the controller, and invoke those ... however, depending on the scale of your RIA, you will quite likely end up with a "fat controller" that is a single monolithic class that contains a great deal of business logic. Using the command pattern allows us to "thin out" the controller, separating the business logic into discrete worker classes that handle the workload of each request. The controller can still be used for common operations such as logging, authentication, etc, that are common across commands - but the commands carry out the "use-case specific" business logic. Sure, there's a performance overhead of using the EventBroadcaster mechanism over just keeping the business logic of each command on methods on the controller; however, building RIAs that will often have 40 or 50 command classes, the benefits gained in making the codebase more maintainable have always outweighed the need to squeeze out a few extra CPU cycles - we've never had problems with performance in this tier of the architecture; data transfer and data rendering are always the points of optimisation. So .... by all means, work with methods on your controller and alleviate the need for command classes; however, as your application scales and your controller gets a little tubby, I'd expect you'll find yourself naturally refactoring towards something like the command pattern architecture. Make sense ? Best, Steven -- Steven Webster Technical Director iteration::two
