[Chicago] Fwd: [Chicago-talk] Updated Meeting Announcement
aaryal at foresightint.com
Tue Oct 11 19:21:00 CEST 2005
On Tuesday 11 October 2005 11:00 am, Ian Bicking wrote:
> skip at pobox.com wrote:
> > >> Please join the Chicago Perl Mongers for an exciting look at two
> > >> MVC web application frameworks.
> > Okay, I'll fess up. MVC has never made any sense to me, at least in the
> > examples I've seen. I've encountered it over and over again in my
> > programming career and for some reason it has just never clicked with me.
> > Maybe all the examples I've seen of it have been examples of MVC done
> > badly. Pointers to lucid descriptions and examples cheerfully accepted.
> MVC in web apps is pretty simple:
> * The View is your templates, or general HTML-generating code.
> * The Controller is the first thing to respond to requests, generally
> performing actions based on form submissions, and fetching any
> referenced objects. E.g., when you access /view?article_id=5, the code
> that gets Article 5 is probably controllerish.
> * The Model is your code and domain objects that aren't specifically
> related to the web. It's Article in this case.
> MVC design tries to keep these three roles separate. In GUI code MVC
> can be a little more complicated, as Model isn't "just" all the other
> code, since often the View and Model are directly connected (so the View
> can immediately see updates to the Model). But since you can't
> immediately see anything in HTTP this is not an issue.
i'll take a stab. :)
the explanation that stuck with me the most was to think of the model as the
entire abstraction of the data constructs that you might have. then, view is
any representation of that data to the user. the most significant thing is
that you can have one 'model'; but you can have multiple views.
for example, in the above example, your model is the 'article' or a collection
of articles. your view might be a 'summary list of articles', nested view of
articles etc. the key point is that the view (or the visual representation)
changes but the underlying data is the same. ie. you have different views of
the same model.
consider a filesystem. the files/directories are your model. in 'file
explorer', you can choose to view it as a list, a tree, filmstrip, thumbnails
etc. these are all different views to the same model. if you change the
model, all the different views get updated. the big idea here is that each
view goes back to some common code/interface - the model - instead of
repeating it within itself.
now, in the web context, i like to think of the controller as the guy that
sits in the middle that takes action on the model (updating/altering it some
way) and then deciding which view to present the model with.
hope it helps.
More information about the Chicago