Is MVC and MVP supervising controller the same?

[reachb4]

Hi,

I have read the following description for the MVC in a website:

In this case of MVC the Controller simply builds the Model and passes it off to the View for rendering. No stateful interplay between the View and Controller, just a “hey, here’s the Model, see you later” from the Controller to the View.

I have read the following about the MVP - Supervising controller

Supervising Controller: The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case it's the Presenter's job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc.

From the description above i feel like the underlying logic behind MVC and MVP - supervising controller are same.

Is my understanding correct?

Thanks in advance,
Joe

[TheGreatCthulhu]

There's a lot misinformation about MVC and MVP on the web, so it's hard to get the gist of it.
It answered your previous question in this thread - you'll find some useful info and links there.

What you must know is that MVC (in it's original form) is an older GUI architectural style, and that MVP is a later variation of it. There are certain significant conceptual differences. Aside from what can be referred to as Web MVC, the MVC pattern is not really used today - and people sometimes write about MVC when they are really talking about a variation of MVP. And sometimes they are just plain wrong.

As explained at your other thread, when people came up with MVC, things were different than they are today. Buttons, checkboxes and other UI elements were just able to draw themselves - they didn't have integrated capability to detect user input (like, from the mouse and keyboard). That was the job of the Controller.

Controller was a class that could figure out what the user was doing, and react to it. The Model object is the data (or represents the data) the Controller works with. The View is the GUI element, and it uses the Model to get the stuff it needs to display (usually, there's some synchronization mechanism involved, based on the Observer pattern (read: events)). The View and the Controller should communicate through the Model, and not directly, most of the time. But they can for certain View-specific (or presentation logic - related) behaviors. For example, a View would talk to the Model to get some data value, but the Controller would be the place to decide if this value should be displayed in a different color, or font, or some other presentation-related style.
(But note that back then, when the Smalltalk community came up with MVC, screens were monochrome... Presentation logic probably wasn't too involved.)

Another important thing to note is that, in classic MVC, there was a View-Controller pair for every single element (button, label, ...) on the screen, as well as for the entire screen.
The whole point is to separate the presentation (View & Controller) from the domain layer (Model), so that the Views don't contain application specific data.
They figured that this way they could make reusable widgets (a.k.a. controls: that View-Controller pairs), that could be used as out-of-the box solutions to build GUI-s for future applications (kind of like what we have today).

Now, over time, GUI elements that are able to detect user input became pretty much the standard, so the Controller as such was no longer necessary. Also, having this design for every single element stopped to make sense - MVP applies to the whole form, not individual controls on it.

With MVP, the part of MVC's Controller functionality in charge of directly handling user input has moved to the View. What's left is the presentation logic, which is mostly the Presenter's job. I say mostly because there are several variations of the MVP pattern. Some of them keep simple presentation logic in the View and have the Presenter handle the more complex stuff, while others leave it all to the Presenter.
So, basically, the idea is that the View gets direct user input, but that it shouldn't really know what to do with it. It routs the calls down to the Presenter. The Presenter then figures it out, and makes the necessary changes to the Model. (The Model models the data layer, and as such it shouldn't have nothing to do directly with Views; it shouldn't care whether it's data is displayed by a desktop app form, or by a console application, or in a web browser.)
Now, how the View is updated is where different approaches to MVP vary.

The Supervising Controller, also known as Supervising Presenter (confusing? yeah, I know... ) is a variation where simple presentation logic is left in the View, while the Presenter is in charge of the more complicated logic (if this is selected, than disable these, change the color of these, rearrange these, hide/show these...). The Presenter achieves this by manipulating the View - which results in a slightly tighter coupling between them.

There is often data binding involved - it's a programming language mechanism that enables you to bind the properties of the control to the underlying data and have them updated as appropriate. These GUI patterns seek to leverage that, and so the View is often data-bound to the Model. Data binding provides an out-of-the-box synchronization mechanism, which is often the most tedious part to write without it. With this setup, the Presenter can update the Model, and the View is updated through data binding, but only where the required presentation logic is simple enough.

Martin Fowler named this pattern "Supervising Controller" precisely to emphasize that this variation of MVP is alike to MVC, aside from the fact that the View now handles user input, and that the pattern is applied at the form level. (funny thing the link to his page says SupervisingPresenter.html )

When articles like that say that the Presenter "handles user gestures" they mean that the View detects input and calls the corresponding methods on the Presenter. With classic MVC, it's the Controller that obtains user input.

Next, there's Passive View: in this variation of MVP, the View gets super-ignorant; it doesn't do anything else aside from the bare bones functionality characteristic to views (drawing itself, making a button look depressed when clicked, stuff like that). All presentation logic is moved to the Presenter, which makes all the decisions. This is mainly done to make unit testing easier. Since the Presenter is in charge of everything, there are no dependencies between the View and the Model in this variation, and that's one of the key differences. User input goes to View, which calls methods on the Presenter, which makes the required changes to both the Model (changes the data) and the View (enables something, shows a tab page, and such...).

There is also the Presentation Model: here, the Presenter, aside from doing what it usually does, also represents a model of the view. It is important to understand what is meant by "model". When you're writing code, you create classes. With classes, you are creating models of real-world objects (like a bank account), or conceptual objects (like a linked list, or a hashtable), or even of operations (e.g. the Strategy pattern). Basically, you are modeling these ideas into their representations that a compiler can understand, and there's often many ways to do it.

Now, as I said, the Presenter is also a model if the view, in the sense that it abstractly represents a view that this application can use. This way, the Presenter can perform view logic, without knowing or caring whether the actual View is made using Windows Forms, or WPF, or Silverlight, or Web Forms, or something else entirely.

It does so by modeling the elements of the view, and usually only those that are dynamic in a given application - the ones that are expected to be manipulated by the Presenter. It defines a set of properties to represent the elements and their specific characteristics. For example, it could describe a text box by having properties for its text, its Font, its enabled/disabled state, and its visibility (assuming that in the specific application only these characteristics are expected to change on the view).

Then it leverages data-binding, where the certain properties of the View are bound to corresponding properties of the Presenter. The rest is the same: Presenter updates the Model, figures out what the View should look like, and makes changes to his own properties, and the result is, via data binding propagated back to the View.
Again, good for unit testing, where mocking frameworks can be used to mock individual elements of MVP to isolate the testing of each specific component. Also, it's more or less designed to take advantage of data binding mechanisms.

You may have heard of MVVM (Model-View-ViewModel). Well, that's just Presentation Model, tailor made for WPF (Windows Presentation Foundation GUI framework), and WPF flavor of data binding. Here, the Presenter is called ViewModel.
Another variant is MVP-VM (Model-View-Presenter-ViewModel), which is just Presentation Model specifically made for Windows Forms (basically, the part that models the view is taken out of the Presenter in a separate object - the ViewModel as it's more convenient, but you can think of it as a component of the Presenter.)

There you have it. Also, read my response in your previous thread, as it contains pretty pictures and more useful links.


EDIT: P.S.
Nowadays, there's also something called Web MVC, and you can find it in ASP.NET MVC framework. This is a web architecture that is conceptually similar to MVC, but again, the pattern is not applied to the level of the individual elements. With ASP.NET MVC framework, this is how the server-side logic is designed: the messages arriving over the web are conceptually considered the user input, and as such go to the Controller object. It then updates the Model (which may represent a database, directory service, or some other data storage system). In this case, the View is not considered to be the GUI of the browser on the client side (remember I said that this is all server-side logic). Here, the HTML page (which is just a bunch of HTML tags, with styles and maybe some JavaScript) is considered to be the conceptual View. So the server just generates the HTML and sends it over the network back to the client. That's where Web MVC as applied in ASP.NET MVC framework stops, and that's where the web browser renders the HTML code. The browser itself may use some of the GUI architectures described above, but that has conceptually nothing to do with Web MVC as described here.

You probably noticed I used the word conceptually a lot: that's because patterns are all about concept, ideas and intent. The exact nuances are less important. No pattern is really set in stone, you can manipulate them, as long as the their fundamental idea remains the same.

P.P.S. D4mn, this post is long!

[reachb4]

Zillion thanks for taking time and pain to write a detailed answer. Your answer is very clear and informative. Bookmarking this

After reading your answer i believe a project/example done true classic MVC is virtually impossible to find in Internet