[Chicago] Fwd: [Chicago-talk] Updated Meeting Announcement

anoop aryal 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 mailing list