Thanks for this and the video.
I sure clears the theory.

Best regards,

-----Original Message-----
[] On Behalf Of Kevin Newman
Sent: zaterdag 18 februari 2012 6:10
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction

That idea that the one thing MVC interpretations have in common - that
models can only be updated by the controller makes sense.

I tried to learn MVC a few times before it really stuck in my head. 
These where the problems I encountered:
- What does MVC apply to? Is it an application level framework, or does it
apply to tiny parts? In other words, do you have one or many in your app?
(the scope the pattern was meant to apply to wasn't apparent from most
- If I have to have a different view for each bit of model data - why bother
with it all (the idea that you should work to make generic reusable views
was never clear from most descriptions.)
- How does the communication work again? Most diagrams are slightly
different from the others and the dotted line connector lines vs. the solid
lines never made as much sense as the road lines metaphor in the diagrams I
linked to.

The video I linked to addressed each of those issues, for the first time.
Really though the problem is there are so many different interpretations of
this "pattern" it's almost not really a pattern at all - more like a group
of similar patterns, and that variance makes it hard to learn and understand
(this thread is kind of proof, IMHO).

What I ended up taking away from that video the first time I came accross it
last year was the model <-> controller side, the idea that the controller
directly manipuates the model and the views - it basically "controls"
things. And the model broadcast tower diagrams for notifying the controller
of changes was useful. I applied the same communication idea to the view
side, as it seemed very iOS specific (even mimicking the UI of XCode to an
extent in the diagrams), and overcomplicated anyway (3 different
communication methods - enough already). I also don't usually bother with
the data source or adapters (but I don't deal with a ton of changing remote
data, usually just an item list that the view can handle).

The guy in the video did slip a little "assume the model and view don't
communicate *for the purposes of this class*" in there - which indicates at
least at a some point having a model specific view makes sense (I do that a
lot - frankly a lot of the UIs I make aren't generic, so why bother with a
generic view framework). It's still mostly MVC in the end, but it's not a
strict implementation of that specific pattern. But when someone is first
trying to learn MVC, the exceptions could be superfluous information the
learner probably doesn't need.

Kevin N.

Flashcoders mailing list

Flashcoders mailing list

Reply via email to