I cannot grok MVC, what it is, and what it is not?

Question

I cannot grok what MVC is, what mindset or programming model should I acquire so MVC stuff can instantly "lightbulb" on my head? If not instantly, what simple programs/projects should I try to do first so I can apply the neat things MVC brings to programming.

OOP is intuitive and easier, object is all around us, and the benefits of code reuse using OOP-paradigm instantly click to anyone. You can probably talk to anybody about OOP in a few minutes and lecture some examples and they would get it. While OOP somehow raise the intuitiveness aspect of programming, MVC seems to do the opposite. I'm getting negative thoughts that some future employers(or even clients) would look down upon me for not using MVC technology.

Though I probably get the skinnable aspect of MVC, but when I try to apply it to my own project, I don't know where to start.

And also some programmers even have diverging views on how to accomplish MVC properly.

Take this for instance from Jeff's post about MVC:

The view is simply how you lay the data out, how it is displayed. If you want a subset of some data, for example, my opinion is that is a responsibility of the model.

So maybe some programmers use MVC, but they somehow inadvertently use the View or the Controller to extract a subset of data.

Why we can't have a definitive definition of what and how to accomplish MVC properly?

And also, when I search for MVC .NET programs, most of it applies to web programs, not desktop apps, this intrigue me further. My guess is, this is most advantageous to web apps, there's not much problem about intermixed view(html) and controller(program code) in desktop apps.

Answer 1

You could start by reading the answers to this question.

Answer 2

I found the MVC paradigm often a lot too bloated. A simple model/view (without the controller) is easier to understand and easier to implement.

Most people understand that some class holds the data (model) and the logic to load/save the data and another class shows that data (view). Give it some glue to load a document (something like a document manager) and you are done.

Answer 3

MVC does fit WebApps nicely. Most of WebApps get the data from DB, process it just a little and show them to the user. DB is your model level, controller does processing and view just emits HTML code.

Some people thinks controllers should just get the data from model and feed it to the view but I think this means the controllers are useless and thus it is just MV programming model :) But I understand them, if you use some kind of processing, you're going to use it more than once and thus it is better to do that at the model level, it can be shared between different parts of applications this way.

You don't have to use MVC for Desktop apps, in fact, I'm not sure this model will work for huge apps, which desktops ones usually are. Too often you want to use a "component", thing that you can feed the same data and get the same UI out of it but in different parts of app, and it just leads to copying code around with MVC.

Answer 4

An "typical" MVC implementation would have:

• views - renders the data for the end user to see and gives them user interface objects to interact with the data (but not to handle that interaction)
• controller(s) - handles the user interaction and manipulation of data traveling between the views and the model
• model - handles storage of data and the representation of that data for the application

A frequent usage of the MVC pattern would be the HTML/CSS/browser rendering for the view portion of a web application, the PHP/scripting language application level acting as the controller, and MySQL or a similar database acting as the model (which may or may not have some sort of ORM framework in front of it).

The truth is, very few people use MVC in exactly this format, and for good reason (in my opinion). Different applications have different needs and design requirements and it's beneficial to bend the patterns to what is needed. These days, "MVC" seems to describe more of the usage of a framework that isolates the layers of an application than the specific model-view-controller pattern.

From an employer perspective, what is really being looked for (oftentimes) is that layer of abstraction and the experience that comes from building an n-layered application. There's a fairly sizable mental jump that happens when you move from working in an app that can be divided up not only into vertical features but into horizontal layers of features as well.

As a note, skinning is really just an aspect of one particular layer, you can change the data sources at the model layer, the methods of manipulating that data (a new algorithm for instance) at the controller layer and roll them out gradually without having to change the other layers.

Answer 5

Maybe following the Wikipedia Article can refer you to more implementations. It has links to implementations of MVC as GUI frameworks.

Answer 6

MVC is a pattern, and it works well with OOP, the two are not exclusive - I'd say they were orthogonal. The MVC pattern attempts to separate the display code (V) from the data (M) and the flow of control (C).

If you search for "MVC .Net" you will almost certainly get a lot of hits for web applications because the ASP.Net MVC framework was recently released, and this is an application of the MVC pattern to ASP.Net programming, hence it is used for developing websites. As you suggest there is no reason not to apply the pattern to desktop apps too.

If you are having a hard time with MVC I would recommend reading up patterns in general to get a feel for how people talk about modeling problems/solutions using patterns, then look at MVC in more detail.

Edit Prompted by the reference to Fowler, his book Patterns of Enterprise Application Architecture is an excellent place to read up on MVC and other patterns.

Answer 7

I like the way Martin Fowler puts it :)

http://martinfowler.com/eaaCatalog/modelViewController.html

.. and from http://martinfowler.com/eaaDev/uiArchs.html :

Take Model-View-Controller as an example. It's often referred to as a pattern, but I don't find it terribly useful to think of it as a pattern because it contains quite a few different ideas. Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.

Answer 8

The MVC paradigm is a way of breaking an application into three parts: the Model, the View and the Controller. MVC was originally developed to map the traditional input, processing, output roles into GUI realm.

The user input, the modeling of the external world, and the visual feedback to the user are separated and handled by model, viewport and controller objects. The controller interprets mouse and keyboard inputs from the user and maps these user actions into commands that are sent to the model and/or viewport to effect the appropriate change. The model manages one or more data elements, responds to queries about its state, and responds to instructions to change state. The viewport manages a rectangular area of the display and is responsible for presenting data to the user through a combination of graphics and text... read more & even more.

Answer 9

At its core, MVC is just a specific case of separation of concerns: One chunk of code is responsible for storing the data, a second chunk is responsible for manipulating the data, and a third takes care of interacting with the user.

Any of these chunks can be implemented in an OO manner, or not - MVC and OOP are orthogonal. (Although, in my experience, MVC applications and frameworks are extremely likely to be OO.)