Search Wiki:
Understanding MVP/MVC is crucial to effectively understanding and using CAB/SCSF

Reference 1
Interactive Application Architecture Patterns - perhaps the most comprehensive document on the matter of the Model-View-Controller (MVC) pattern and Model-View-Presenter (MVP) pattern. For accuracy purposes I used the images from the referenced document below.

Reference 2
Designing Smart Clients Based on CAB and SCSF by Mario Szpuszta, Architect | Microsoft Austria.

Reference 3
MVP: Model-View-Presenter, The Taligent Programming Model for C++ and Java by Mike Potel, VP & CTO, Taligent, Inc

Had I read the above documents (and understood them) prior to starting with CAB, and later SCSF, I would have understood what was going on, the learning curve wouldn't have been so steep and I wouldn't have made so many mistakes in how I utilized CAB/SCSF.

MODEL .... Data and Business Rules

VIEW ...... User Interface (visual representation of the Model)

CONTROLLER/ PRESENTER .... Communicate with the Model and the View (distinction - levels of abstraction)

Those of you that are familiar with MVP and MVC are probably thinking - Ah-HA! he doesn't know what he's talking about - everyone knows that "the big difference between MVC and MVP is that with MVP, the view is completely controlled by the Presenter, whereas in MVC, the controller and the model can update the view". I quote Reference 2 on the top of page 11.

You have to consider the source - literally ;) The MVC pattern originated in 1978-79 (Smalltalk-80); you can read reference 1 for the details. MVP was first formally described by Mike Potel in 1996 (Taligent, Inc) reference 3. Studying the founding father's documents on MVP and MVC you start to see that the big difference is misunderstood... The distinction is in the "Benefits of Abstractions" (see this section in reference 3)

As you look at the image above you'll see that the following is accurate:

CONTROLLER/ PRESENTER .... Communicate with the Model and the View (distinction - levels of abstraction)

In the shadow of this knowledge I would think ... Ah-Ha! They don't know what they are talking about - as I researched MVP and found that a large majority of people shared the misconception that the primary difference is that with MVP only the presenter communicates with the view.

So where did this notion come from and why is it so widely accepted as the "big difference"? You have to consider the source:

Martin Fowler Wikipedia on Martin Fowler anyone who has studied architecture, MVC and MVP will know who he is; almost any reliable source that I have used in my architecture research has referenced him. In 2006 Martin Fowler split the MVP pattern into two, the Supervising Controller and Passive View. The Supervising Controller is the SmallTalk 80 MVC pattern referenced above and the Passive View pattern is the pattern that is widely accepted as MVP (even though Fowler suggest that passive view doesn't not apply if databinding is used).


The Microsoft MVP patterns conceptually lean towards the Fowler Passive MVP Pattern - I say conceptually because if you use databinding then you broke the mold - via the observer pattern you have established an indirect link between the view and the model where the view observes the model for data changes. More on this by Fowler reference paragraph under figure 6

Reference 1 is perhaps the most comprehensive document that I've come across (wish I had seen it first a long time ago). Unlike any of the others it incorporates the following which shows (Passive MVP) the Application Controller or Presenter updating the view upon model data changes:



So do you see the pattern? If so, then can appreciate CAB/SCSF for what it is, and what your programs can become, an example of architectural excellence. As for the learning curve - all you have to teach folks is how to right click, select a "recipe" and where to put their business logic :)

Last edited Jul 4 2008 at 7:50 PM  by BillKrat, version 39
DeepCore wrote  Jan 11 2011 at 9:11 AM  
Correct link for reference#1:

Page view tracker