It's not so much a feature as an architectural goal. In an MVC architecture, you want your views, commands, and data model to be as independant as possible. In your case, let me describe a simple, example scenario.
Let's say your View, in which you've hard coded a relationship with a Command, gets included by another developer to use in her project. In this other project, another Command is needed that is slightly different from yours. Instead of simply being able to use your view natively, she will have to create a separate copy of it, and then modify it to use her Command.
However, if you simply dispatch an Event, then the View can be used n number of times in n number of other projects completely unchanged. All the other developers need to do is change which Command that Event is mapped to.
This is one of the concepts behind MVC - decoupling, as much as possible, the different layers of your application.
Hope that makes sense.
thanks for your helpful answer and the good example . I certainly agree to the theoretical idea but nevertheless feel
-to leave out this extra layer of abstraction is not much of a problem because:
- As far as I remember back I have never reused a view "as is" in any two projects. Therefore I think this might be more relevant to component providers than developers of individual software
- I guess the view can still be reused. If a different behaviour is needed the command can be copied and adapted. Sure you can not change the method signature but the payload would also be defined by the event which you could not change without changing the view. You also could not map a completely differenct command to the event but did you ever want to do this?
-and that in practice it might be easier to directly call the command from the view because:
- I do not need to create cairngorm event
- I do not need the controller class to map events to commands (obiously I need the controller part (from MVC) but that are the commands)
I think the last mentioned practical advantages might outweight the rearly used advantage of "as is" reusability of the view.
Best and thanks again for your comment,
And now you've touched on the ages-old debate on whether a code architecture is needed or not. For many smaller, or one-shot projects, a code architecture simply serves the purpose of code management - whatever the developer is comfortable with. Although in many cases, a framework or architecture is simply not needed.
However, where I work, we are building enterprise scale portal user interfaces where views, and view components, are reused many times by different applications. In this case, having a consistent code architecture that enforces separation of concerns is vital and necessary.
As many have said in the past, no code framework or code architecture is a silver bullet that should be applied in all cases. They have pros, and they have cons. You simply have to weigh these, and then when the pros outweigh the cons you know you're ready to use it.
Thanks again for your reply. I certainly agree with your last paragraph.