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 descriptions.)
- 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@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
