MVC stands for Model-View-Controller framework which is designed by microsoft for ASP.NET.
ModelsModels represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.There should be a one-to-one correspondence between the model and its parts on the one hand, and the represented world as perceived by the owner of the model on the other hand.
- ViewsA view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter.A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will therefore have to know the semantics of the attributes of the model it represents.
- ControllersA controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on to one or more of the views.
It may seem like we’re deep in Architecture Astronaut territory now, but bear with me. The MVC concepts are a little abstract, it’s true, but it’s an incredibly common pattern. It is literally all around you. In fact, let me bring it back down to Earth this way: you’re looking at MVCright now.
|Model = HTML||View = CSS||Controller = Browser|
This ubiquitous trifecta represents MVC almost perfectly.
- ModelThe HTML is the “skeleton” of bedrock content. Text that communicates information to the reader.
- ViewThe CSS adds visual style to the content. It is the “skin” that we use to flesh out our skeleton and give it a particular look. We can swap in different skins via CSS without altering the original content in any way. They are relatively, but not completely, independent.
So if you believe the web has been at all successful — most signs I’ve seen point to yes — then you also have to acknowledge the incredible power of Model-View-Controller.
It’s no coincidence that many of the most popular web programming frameworks also encapsulate MVC principles: Django, Ruby on Rails, CakePHP, Struts, and so forth. It’s also officially creeping into ASP.NET under the fledgling ASP.NET MVC project.
Just take a gander at the project layout in a sample ASP.NET MVC project:
It’s almost self-explanatory, if you’ve ever built an application of any kind:
- ModelThe classes which are used to store and manipulate state, typically in a database of some kind.
- ViewThe user interface bits (in this case, HTML) necessary to render the model to the user.
- ControllerThe brains of the application. The controller decides what the user’s input was, how the model needs to change as a result of that input, and which resulting view should be used.
Here’s one quick way to test if your application has properly segregated itself between the Model, View, and Controller roles: is your app skinnable?
My experience is that designers don’t understand loops or any kind of state. They do understand templates with holes in them. Everybody understands mail merge. And if you say, “Apply the bold template to this hole,” they kind of get that, too. So separating model and view addresses this very important practical problem of how to have designers work with coders.The other problem is there is no way to do multiple site skins properly if you don’t have proper separation of concerns. If you are doing code generation or sites with different skins on them, there is no way to properly make a new skin by simply copying and pasting the old skin and changing it. If you have the view and the logic together, when you make a copy of the view you copy the logic as well. That breaks one of our primary rules as developers: have only one place to change anything.
Skinnability cuts to the very heart of the MVC pattern. If your app isn’t “skinnable”, that means you’ve probably gotten your model’s chocolate in your view’s peanut butter, quite by accident. You should refactor your code so that only the controller is responsible for poking the model data through the relatively static templates represented by the view.
The power and simplicity of properly implemented MVC is undeniable. But the first step to harnessing MVC is to understand why it works, both on the web, and also within your own applications.