MVC
This is one of the most commonly hear/read concepts lately. It appears that everyone around the world (I’m talking about job applications here) requires developers that know what is and how to develop according to MVC. By the end of this article, you will know what it strikes me as strange that job applications for SharePoint require developers to know how to program according to MVC.
First of all, what does MVC stand for and what is it? MVC stands for Model-View-Controller. The hyphens between the words are obviously there for a reason. Some people tend to read MVC as “model view controller”, as if it is a controller that models views. Obvisouly, that is not the case. In order to better understand however, what Model-View-Controller is all about, we should first focus on what problem it is supposed to resolve.
The problem that is addressed by MVC is that of the data that comes from a data store, displayed to a user interface and then, once the data in the user interface has been updated, it is saved back to the data store. Although the developer might be inclined to tie the processes together, the cases where data display and data update can be tied are far from common. Most of the times, there is some sort of business logic in between the steps and furthermore, most of the times, the user interface will update many more times than the data store. MVC refers to web technologies (that is why ASP.NET job openings will almost always require developers who can code according to MVC) and the problem it resolves, is the modularization of the user interface so that the individual parts can easily be modified (when needed).
The specific issues that arise when developing web applications that deal with data stores (which, is almost always the case) are the following:
1. as mentioned earlier, user interface logic tends to alter more frequently than the actual business logic. The interface (presentation code) needs to be separated from the business logic (the code that performs the actual operations) otherwise, each time some change is made to the interface, the entire application will need to be redistributed.
2. web applications should allow users to display data from the data store in the way they find more useful. For example, management may require pie chart views, while logistics personnel might require spreadsheet views. These views should be separated so that when one user changes his/her view, the rest of the users should be able to use their own personal favourite views.
3. visually appealing user interfaces will not -in most of the cases- be something that the developer responsible for the business logic programming will be familiar or inclined to do. The two programming aspects should be independent.
there are more “forces” that come into play when thinking about web applications. For a better understanding, make the jump to the MSDN explanation here.
The Model-View-Controller patters, splits the modelling of the domain, the presentation and the actions based on the user input into three separate classes. Taken “as is” from the MSDN article:
-Model. The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
-View. The view manages the display of information.
-Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.
It becomes apparent from the diagram that, both the Controller and the View depend on the Model but the Model depends on neither of the two. This separation allows the model to be built and tested independent of the visual presentation. On the other hand, the Controller and the View might even be incorporated into one object but not when creating Web Applications since there, the separation between the two (ie. the view, which is the browser and the controller which is the server-side components handling the HTTP requests) is very well defined.
Now, you’ve read through the explanation and the usage of the Model-View-Controller and you’re probably thinking, why did I say that it is peculiar that job openings for Sharepoint professionals require the developer to program according to the MVC pattern. The reason is simple and actually quite absolute: SharePoint does NOT support the MVC pattern. SharePoint DOES support the MVP pattern, which however, is not preciselly the same as MVC.
MVP
MVP stands for Model-View-Presenter (same difference, you might think but that’s not the case) and the main difference between MVC and MVP lies (mainly) with the presentation segment of the pattern. In MVP, the Presenter (which takes the Controller’s place) will deal with the rich UIs that allow to translate mouse gestures, etc. aspects that the MVC was not built to deal with. The UI in MVP gets a bit more power. According to Phil Haack, with MVP, GUI components themselves initially handle the user’s input, but delegate to the interpretation of that input to the presenter. You could, and probably should, make the jump to the original post by Phil that may clarify the difference between MVC and MVP even more. As always, the MSDN resource explains it quite clearly, although you might (like me) find it hard to pinpoint the exact difference between MVC and MVP. Phil probably does a better job as far as that little bit is concerned.
As already said, MVC and SharePoint do not mix. Because of the rich user interface, SharePoint development should always follow the MVP pattern.
Powered by Zoundry Raven
