Model View Controller 
Author Message
 Model View Controller

I've been trying to find out more about the
model-view-controller architecture/pattern.
I have MANY links, white papers, 4 books, etc.

But I still can't find out --

     What are the shortcomings of MVC?!?!

I've got a couple links to model-view-presenter,
but they're not clear -- what's the change?
And how is it improved?

Also, any other competing UI architecture patterns
would be appreciated.  Thanks.

Burton

P.S. Am looking at:
Gang of 4 chapter on Lexi
Pattern-Oriented Software Architecture: A System of Patterns



Wed, 18 Jun 1902 08:00:00 GMT  
 Model View Controller
Burton,

Quote:
>I've been trying to find out more about the
>model-view-controller architecture/pattern.
>I have MANY links, white papers, 4 books, etc.

>But I still can't find out --

>     What are the shortcomings of MVC?!?!

>I've got a couple links to model-view-presenter,
>but they're not clear -- what's the change?
>And how is it improved?

>Also, any other competing UI architecture patterns
>would be appreciated.  Thanks.

During the development of Dolphin Smalltalk we went through three iterations
of UI framework; eventually settling on Model-View-Presenter (MVP).

1/ Our first attempt was a "widget" based system that was similar to Visual
Basic's VBX/ActiveX controls and Java Beans. We found this too limiting
since it seemed we were always duplicating code between similar widgets
and/or over-factoring the code to gain re-useabliity.

2/ The next stage was to impement an MVC scheme not disimilar to the one
around which VisualWorks is based. We also found problems with this, mainly
stemming from the loose (Observer) coupling between the application model
and the view. We were finding very often that the application model does
need a hard coupling to its view but that this is awkward in a traditional
MVC scheme.

3/ As a third pass we eventually came across MVP (based around work done by
Taligent as a C++ framweork) which skews the triad so Observer is still used
but the presenter (the effective application model code) does have direct
access to the view.

I've probably confused more than I've helped here but there's a page on our
website that sets out the problems we found with MVC with a few pictures to
aid understanding. Its at:

http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

Best regards,

Andy Bower
http://www.object-arts.com

---
Visit the Dolphin Smalltalk Wiki Web
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---



Wed, 18 Jun 1902 08:00:00 GMT  
 Model View Controller

Quote:

> I've been trying to find out more about the
> model-view-controller architecture/pattern.
> I have MANY links, white papers, 4 books, etc.

> But I still can't find out --

>      What are the shortcomings of MVC?!?!

One shortcoming of MVC is that there isn't anything analogous to MVP's
"presenter" (more on this below).
Another shortcoming is that the distinction and interaction between
"view" and "controller" is not often a useful thing to focus on.  Most
of  the components available to a programmer encapsulate both view and
controller functionality so their relationship is hidden from the
programmer.  MVC is a pattern of the internals of a GUI widget as well
as the model/GUI coupling.

Quote:

> I've got a couple links to model-view-presenter,
> but they're not clear -- what's the change?

Here's my interpretation of MVP:

The "view" of MVP is a GUI widget (MVC's "view" and "controller" wrapped
up in a single object).  The "model" of MVP refers to domain objects
(e.g. database stuff) that have no dependencies upon (nor knowledge of)
the GUI system.  The "presenter" is the glue.  It has knowledge of the
model and the view.  The "presenter" knows how to get data from the
model and massage it into a form usable by the view.  The view informs
the presenter of user actions and the presenter will in turn request the
model to update itself accordingly.

Visual Smalltalk actually had two separate frameworks that fit the above
description, although neither was called "MVP" ("View Manager" and
"Application Coordinator" were their names).

Quote:
> And how is it improved?

MVP has evolved from MVC.  MVC addresses both the implementation of GUI
widgets and the coupling of GUI widgets to the model, while MVP doesn't
so much cover the implementation of widgets but focuses on the
integration of widgets and the model, and this reflects the fact that
most GUIs today are built with off-the-shelf widgets and widget
implementation is not a common task.

The introduction of a "presenter" is an important evolutionary advance,
IMO.  In MVC the glue that held everything together was the change
notification mechanism that was an integral part of the Smalltalk-80
class libs.  The model was coupled to the view by making the parts of
the view "dependents" of the model objects, so that whenever a model
object changed the dependent view parts would be notified.  Significant
behavior of the GUI was defined by making views dependents of model
objects.  It's neat, kind of magical, but it could be more directly
expressed.  Creating a "presenter" object (A.K.A. "ViewManager" A.K.A.
"ApplicatoinCoordinator") to contain and centralize the essential
behavior of the GUI is a more direct and obvious, IMO.  Presenters play
a central role, and that role be identified, named, and be allotted a
piece of the acronym.

...Mike



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. C++/Views: A Model-View-Controller Library for C++

2. Looking for implementation info on Composite Model-View-Controller architecture

3. Model View Controller

4. Looking for info about Model-View-Controller paradigm

5. Model View Controller and Ada 95

6. Model-View-Controller

7. The origin of Model-View-Controller

8. Model-View-Controller concepts...

9. model-view-controller info

10. Model-view-controller

11. Model-View-Controller

12. Is the Model-View-Controller concep

 

 
Powered by phpBB® Forum Software