Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

| * |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / General Discussion / In MVC systems, why doesn't controller observe model? on: October 13, 2011, 07:00:07
PureMVC has opened my eyes in a lot of ways. I had been struggling to understand MVC for a long time. One thing I could never understand (at least in terms of Flash and AS3) was why the View should delegate events to the Controller. Suppose I have a group of buttons in the view, and they are in an array (also defined in the View), and they share an event listener. The first thing the listener does is figure out which button was clicked using event.currentTarget.

The View can do this because it has the array and all the references to the buttons. If I pass the event to the Controller to process it, the Controller will not have the array reference, nor any references to any of the other buttons, and so some other way must be found to identify the button. Using the name property might be a solution, but then the same problem pops up: the Controller then needs to know all the names.

The book "Actionscript 3.0 Design Patterns" advocates passing the event to the Controller to handle it. Their scenario goes like this: Model is instantiated first.
The Controller is instantiated and given a reference to the Model in its constructor.
The View (or views) is then instantiated and given reference to the Model and Controller.

Notice that, in the above, the Controller is never given a reference to the View, although the authors seems to indicate that the Controller can have a reference to its view, and even should in some cases.

However, the book "Head First Design Patterns," while not an AS3 book, seems to advocate a system something like this:
Model is instantiated first.
The Controller is instantiated and given a reference to the Model in its constructor.
The Controller then instantiates its View and passes a reference to both the Model and itself to the View's constructor.

Since the Controller now has a reference to its View, it could then freely add event listeners to the View's buttons itself. The Controller could then house the array that refers to the View's buttons, like:

private var buttonArray:Array = [view.button1, view.button2, view.button3];

In this scenario, the View becomes something like the view components of PureMVC. They can be reused in another project by simply writing a new controller for them.

My question, then, is-- doesn't this kind of system-- where the Controller becomes an observer of its View-- just make a lot more sense? I mean, the View still communicates to the Controller, it just does it by dispatching events (instead of just passing them directly). I don't see the downside, and I wonder why so many sources advocate passing an event to a Controller that just doesn't have the right references in place to handle it.

Studying PureMVC has made me aware of this. I love the way it decouples everything. In PureMVC the Mediator classes observe their view component much like my hypothetical controller above.

Any thoughts?
Pages: [1]