Idea Transcript
Custom Search
JetBrains Rider: new cross-platform .NET IDE. Develop .NET, ASP.NET, .NET Core, Unity on Windows, Mac, Linux
See how your visitors are really using your website. ads via Carbon
Mobile Developer - React Native Zego
Kansas City, MO
$65K - $85K
javascript
react-native
App Developer Cremalab
Kansas City, MO
api
Be one of the first applicants
Continue Discussion 127 replies TimM
May '08
While MVC is a good pattern, its worth taking the time to understand its more modern counterpart - MVP (model view presenter). In fact many so called MVC implementations are actually MVP. There are many articles on this but the best in my opinion is the experience report of Andy Bower and Blari McGlashan at ESUG2000 (http://www.object-arts.com/papers/TwistingTheTriad.PDF) The neat thing about this paper is that it actually gives a first hand account of exploring MVC and then discovering that MVP is more appropriate. Even neater still is that you can actually see and use a very clean implemenation of MVP in Dolphin Smalltalk (yes the S word again). Get a copy of the free Dolphin and actually visually create a View, and then hook it up to a model with a presenter. Then realise that you can then use that new “triad” as a sub component - simply genius, and something that hasn’t had as much credit is it should have. Tim 1 reply Matt
May '08
This is complete and utter hogwash. You start off by saying that the standard web is a great example of MVC. You INCORRECTLY state that HTML is the model and CSS is the view. Yet I can have pure HTML with no CSS at all (like in the old days) and still give the user a view into data sitting on the server. You then go on to quote someone who corrects you stating that HTML is actually the view and the model is actually data and objects sitting on the server. I’m not sure that I am buying that either but it is at least much more paletable than your original stretch. But then you go on to say that skinning has something to do with how well we’ve implemented the MVC pattern. Yet many apps exist that are supposedly skinnable that don’t follow the MVC pattern at all. It is true that if you follow the MVC pattern your app is more LIKELY to be easily skinnable. But just because your app is skinnable doesn’t mean that it is a good implementation of MVC. If you’ve done one thing right it’s to show that the whole concept of what MVC actually means is open to a wide array of interpretations!
KevinT
May '08
Applications interact with users and present data. The separation of interaction, presentation and data is one that comes fairly naturally to an experienced programmer - this doesn’t need to attribute itself to the idea of MVC though. A problem with MVC is that it’s so generic it can apply to almost any architecture that isn’t total spaghetti code. This makes new programmers feel stupid since they will gain understanding of a particular flavour of MVC, and then run into a different flavour and think to themselves, “hmm, I guess I don’t understand MVC after all.” Eventually they realize that the term MVC is so broadly applied to that it doesn’t convey much information unless qualified with a particular flavour of MVC, e.g. “Smalltalk MVC” , “Cocoa MVC” or “Rails MVC”. In web applications the term MVC is particularly meaningless and overused. Django was created without MVC in mind, but it’s a well designed framework, so it’s easy to say, “oh the views are the controllers and the templates are the views”. Rails Controllers have a render method and provide data to the Views, which goes against the Smalltalk MVC of “[the view] gets the data necessary for the presentation from the model by asking questions.” If Smalltalk MVC and Rails MVC are fairly different does this mean one is “wrong” and the other is “right”? No, of course not. But adherence to the idea of MVC encourages people to try and force everything into only three types of components. Do permissions get handled by the controller or the model? What about observers/subscribers? There are lots of parts in a web application that don’t fit cleanly into MVC. Anytime your application has heavy base classes or people recommend a “fat model” it probably means that you should have more than three types of holes to pound your code into …
Rich
May '08
Nice to see you blogging about code again, Jeff.
Martin
May '08
Another big problem with MVC is when two MVC frameworks collide. Having a UI toolkit that also does MVC means, in Java Swing for example, mapping your UI control’s data model to your application’s data model. Add a binding framework or an ORM, and you’ve got model-to-model translation code coming out of your ears.
DanielL
May '08
@zeroth: Thanks for the explanation. But in Trygve’s definition for view I read: “It may also update the model by sending appropriate messages”. So when would you update the model directly from the view and when using the controller?
Max_Cantor
May '08
Can you think of any situations in which MVC might speciously appear to be a good solution, but would actually make things more difficult or less maintainable?
RickB
May '08
Sounds like there is disagreement and misunderstanding I don’t claim to offer the “correct” answer, but I will define how I have been applying MVC to good effect lately. Model – Data only. Get methods, set methods, etc. It is isolated – it knows nothing about the View, nor the Controller. View – UI only. Dumb or “humble”. Only shows what you tell it to, and never performs any transformation or validation logic – e.g., it always forwards input via an event/callback system. It is isolated - it knows nothing about the Model, nor the Controller. Controller – Sits between Model and View. Does any data transformation (business logic) that is necessary to get the data from the Model to the View. Does most data validation on input that comes back from the View. It “knows” about both the View and the Model. With this definition it becomes much easier to divvy up work between engineers. If someone is a database engineer, they probably don’t know UI. But they can write the Model to great effect, and hey maybe they can stub out a crappy-and-simple View. Maybe it’s simply a text dump of the data, that’s fine. At least the code-level interface is in place. Then the UI developers can come and write the Controller and View. Then when the UX designers change what they want the UI to look like, you can either change the View or write a new one. Or if you want to use different UI technologies – WinForms on XP, WPF on Vista, or Cocoa on MacOS, then just have different View implementations for each. Things like skinning are then easily isolated to the View pillar. The other useful pattern to employ here is an Inversion of Control (IoC) container/scope object. None of the classes participating in MVC need to know about the specific implementation of each other, just the interface/contract. This makes it trivial to unit test the Controller with faked out View and Model implementations. The Controller just says, “hey Create me an instance of I____View” … and your unit test harness just happens to be providing it the Mock____View instead of the ____View that is used in production.
RHH
May '08
Seems a stretch to consider a browser a controller. Typically a controller can modify the model. A browser typically isn’t used to modify the HTML it receives.
Nick_Argall
May '08
If you’re using a modern IDE (such as Delphi, VB, or C#) then you must understand the little-known ‘Document-View’ pattern in order to properly evaluate MVC. Most IDEs implement the Controller for you, meaning that implementing it again is counterproductive.
DiegoC
May '08
Jeff, if the view is “a (visual) representation of its model” then I think CSS wouldn’t be the view in your example because it determines HOW your model will be represented and not what your model represents. I am wrong?
Gaurav
May '08
Very informative post for a university student who is taking a web authoring unit next semester. Thanks for shedding light on the MVC model, will definitely read more about it and implement it from start.
codinghorror
May '08
You then go on to quote someone who corrects you stating that HTML is actually the view and the model is actually data and objects sitting on the server. I’m not sure that I am buying that either but it is at least much more paletable than your original stretch. There are two different examples of MVC presented in the above article: 1. Web content 2. Three-tier web development I believe both are completely valid examples of MVC. The web content example may be a distraction for hardcore software developers, but I believe it is an excellent (and completely valid!) illustration of the benefits of MVC to a layperson or casual programmer.
codinghorror
May '08
I think CSS wouldn’t be the view in your example because it determines HOW your model will be represented and not what your model represents I don’t understand this criticism. Here’s what Trygve defines a View as doing: "A 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. " Isn’t CSS used to do exactly this on the underlying HTML? make this bold increase the size of this move this DIV over here hide this content place this background image here It’s the very definition of a “presentation filter”, ala CSS Zen Garden. http://www.codinghorror.com/blog/archives/000474.html
Niyaz_PK
May '08
The only problem with MVC is that for very small apps, its kind of a big overhead. Also in the case of web apps, we cannot seperate logic from presentation completely.
codinghorror
May '08
in the case of web apps, we cannot seperate logic from presentation completely. You can also see this with HTML+CSS ; having a totally skinnable set of HTML means constructing the HTML markup with CSS design in mind. For example, you shouldn’t use IMG tags but instead replaceable DIVs…
Joe_Beam
May '08
I made a couple sites with struts like 3 years ago. It really forces the MVC pattern. There’s a good description on their homepage. http://struts.apache.org/primer.html#mvc
MichaelF
May '08
You should see what else Trygve Reenskaug has been up to. He’s still workin in Norway and he has some interesting ideas about how to go beyond MVC.
david14
May '08
Moving from the traditional ASP.Net model to ASP.NET MVC Framework definitely helped my four-month old, facebook-app/dev startup tremendously. It’s fantastic. I highly recommned it. Though not a silver bullet, it definitely allowed my friend and I work to more effectively. I’m really glad you took time to shine some light on this topic.
dbr
May '08
For example, you shouldn’t use IMG tags but instead replaceable DIVs… No! Not always - images can be part of the content. For navigation links and such, yes, use the div background-image property but for a photo (for example), you should defiantly use img tags… Your web-page should be completely readable with CSS disabled - if you display images via div tags, you cannot see them… (I’m sure you already know that, I was just clarifying…)
Shmork
May '08
I have to admit, as someone with more philosophical inclinations, I wonder whether the stated goal of totally separating content from representation is even a good idea. Certainly no graphic designer would sign on to that theory of the world, much less a philosophically inclined graphic designer. The world is not actually made up, ontologically, of objects whose logical value and whose representational value is totally separate —they are deeply intertwined. I understand, of course, the practical benefits from doing such splitting. But I find it quite odd that computer people on the whole seem to think that this approach is a really elegant one. It’s an idea which anyone in the humanities would find amusingly bad, one whose limitations are going to be on display constantly (as an example, witness how much hacky-looking CSS one generally needs to use in order to take a given HTML structure that was set up for a given page appearance to actually make it look totally different).
Rob_Russell
May '08
I’m a big fan of design patterns applied correctly. My framework of choice lately has been CakePHP and I’ve been surprised at the number of places that MVC /is/ a good fit. I’ve found that MVC is a great and widely applicable pattern but it still isn’t a one-size-fits-all. For example, you’re not going to get a lot out of MVC if your application is a virus scanner, a screensaver, a CPU-heavy command-line utility, etc. There may be small ways to apply MVC in those places but you’ll find that you’re twisting the pattern and becoming very fat in one of area - models, views or controllers - while the other areas are basically empty. MVC doesn’t just have to be forms and responses though, there are a lot of cases where an interactive web application fits very nicely into the Model-View-Controller pattern and the overhead is well worth the cost. If the application scales up a lot then you might need to tweak things and rearrange your framework, but MVC and a good framework are what get you 80% of the way there.
BrianK
May '08
Unfortunately, my only real exposure to MVC so far was via Ruby on Rails… Combine the 2 and you have a real mess on your hands. Sure, the separation of task is great for not breaking functionality, however debugging becomes exponentially harder as projects increase in size. Mostly due to the way Ruby on Rails works (great for quick dirty small projects, but doesn’t scale gracefully), but the MVC model does have some small part in helping to magnify that particular issue…
bryan6
May '08
Is this just another flavor of 3 tier architechtre(interface,business logic,data)?
Mike
May '08
I’m not sure I understand the overhead argument. How does MVC introduce overhead, even in a small app? Seriously, your data is likely in some kind of structure already so views should be a no brainer. What usually happens from my experience is controller logic gets mixed in with the views.
Mo110
May '08
I tend to find that any application of a sufficient size which is continually evolved in a logical direction will eventually end up following the MVC pattern, or some variant of it. @Shmork: The total separation of content from presentation as it exists in the Web world isn’t ideal, but that’s largely because neither CSS nor HTML are perfect—CSS didn’t exist for a long time, which meant things got all screwed up. It is, however, considerably preferable to the alternative, as anybody who actively used the web in 1998 will likely testify. HTML was invented to convey information in an agnostic fashion, and styling “layers”of some kind are a perfect fit for that—the issue is the implementation, not the theory behind it.
Jeffrey04
May '08
I applied MVC in my final year project and it helped us to decrease some development time.
a1115
May '08
My favorite thing about CSS is that you can turn it off. All those news sites with tiny text and layouts that break when you size it up? Boom, disable CSS. All those sites locked to 700 pixels wide on my 1920 pixel width monitor? Again, no way I’m using that CSS.
experienceda
May '08
There are many 3-tiered architectures, but MVC is not [HTML, CSS, browser] nor [interface, business logic, data]. MVC = [model/business logic, view/representation, control/interaction logic]. The design pattern is typically used in rich client applications, not in web sites. A typical website has the model shared between the server and the client-side scripting, has the representation shared between the HTML, CSS and the UI of the browser itself, and has the control shared between the Javascript in the HTML and the logic of the browser. This does not mean that the separation of concern as seen in [HTML, CSS, browser] is pointless, far from that. It is just something different.
DuncanW
May '08
Proper MVC makes it trivial to have multiple views of the same model, for example two photoshop windows of the same bitmap at different zoom levels. While this can be done without MVC, putting all your view state in the view code is the straightforward (and correct) solution.
John
May '08
I’m a big fan of MVC, but what I’m having trouble understanding is when to use it and when not to. Rob, I agree with you that its not a one-size-fits-all solution. So when does it make sense to use it?
bp12
May '08
Ah, the joys of using XAML for markup. This sort of thing is easy then. Skinnable apps are awful though and should never be encouraged.
Paul_Houle
May '08
To me the key idea of “MVC” frameworks for the web is to separate the code that processes form input from the next page that gets displayed: the form processor gets to decide what template is used for the next page and passes variables to it to fill in various slots. I’ve been working with ASP.NET lately, and in a lot of ways it’s a really great system. Yet, the Web Controls have a poorly conceived “viewstate” mechanism that’s incompatible with the ability to display different forms depending on the results of the processing the first form. (Not to mention incompatible with the back button, etc…) Java Server Faces have a similar problem. There’s a strong need for a web widget set that makes it itrivial/i to implement data validation, multi-part forms and other things that are tedious in conventional web apps.
Wordo
May '08
m = xml, c = xsl, v = html+css+js, html, wml, audio, etc. Mike
GrahamS
May '08
Before everyone starts commenting on writing hacky CSS and having to bend the HTML ‘model’ to suit the CSS ‘view’: Yes that happens, but it is a failing of CSS (and particularly in poor browser support for CSS features) rather than a general failing of the Model/View/Controller pattern.
Osmyn
May '08
A litmus test I keep in mind while designing is if I can substitute something other than a standard web page for the view; like a mobile browser view, or even a desktop app gui or command line. The power of the pattern is apparant to anyone who has needed to write an app that works on the browser and desktop!
HvardP
May '08
For niyaz pk and others who think MVC must be large and cumbersome, I’ve implemented the smallest useful subset of the MVC model as a “framework” in a single PHP file of 30 effective codelines. http://www.pmedia.no/off/ And I have actually used it for several procjects, some larger than others.
tkim
May '08
This comment is little off to the tangent but I hope you have IE6 available on your machine because you want to test websites. And you don’t use it for everyday browsing. (else my respect for you as a cutting edge geek will drop 10 folds…)
Alex_Fort
May '08
This is a very good method of design, but for some programs it just won’t work without making everything a bit harder than it needs to be. Consider a simple task oriented web service. There’s no real front end, besides a SOAP of XML transaction acceptor, so abstracting out the “front end” would be utterly pointless, unless you just want to have your program structured that way. All in all though, it is a very good design theory.
David_H
May '08
Thank you for posting this, Jeff. I’ve been trying to understand MVC for some time now.
Rick_Cabral
May '08
Beware the kid with the new hammer, everything’s a nail. Those that are currently rabid about patterns be forewarned: The book that spawned the term (Gang of Four) was groundbreaking at the time, but more of an exploration of a metaphor than the rulebook some organizations have made it. The hypothesis: Is it possible to create programming “jigs” that would allow programming “craftsmen” to solve problems rapidly. Are there some fundamental building blocks upon which greater applications are built? The metaphor applies about as often as you’d expect: 50% of the time. Keep in mind that human minds are hard-wired to find patterns among chaotic structures, and programmers are better at it than most. I got into patterns long after I started programming and found (to my surprise) that I had been using the concepts without knowing for many years.
D1183
May '08
Would a better model in this example be XML? How can HTML (a markup language) be a good example of a model (data)? I thought the model in MVC was supposed to be view independent.
Noah_Slater
May '08
“For example, you shouldn’t use IMG tags but instead replaceable DIVs.” I don’t know if I should laugh or cry.
paul10
May '08
Again with the giving credit to only Smalltalk people! We owe everything to lisp doggone it!!! Okay, deep breath, I feel better. Seriously, thanks for this article and breakdown. I would argue, as one other poster did, that the browser contains both view and controller. The CSS handling and page rendering is, I believe, view logic not controller. The linking etc is definitely the “routing” portion of the controller.
GrahamS
May '08
@Noah Slater: as dbr clarifies above, using DIV (or other suitable tags) instead of IMG does actually make sense when the design element in question isn’t (semantically-speaking) an image.
MoffDub
May '08
This is why I am a fan of this blog. I’ve had this very same discussion in my head a while back. What I don’t like about the original definition of MVC is the link between the View and the Model (how a View “attaches” to a Model). I tend to, as Jeff did in the rest of the post, detach these two completely. Only then, I think, can your app be truly “skinnable.” The View should be “dumb”: some meaningless (domain-meaningless) interface through which it receives data and barfs it on the screen and into which it can take user input and barf it to the Controller. The Model is the domain model plus data access. Straightforward. The Controller is…everything else. Receives the domain-meaningless barfed output of the View, fiddles with objects in the Model, determines the next View to be displayed and displays it, passing more data to the View via the domain-meaningless interface. That way, whether your View is Windows Forms, ASP, whatever, all it needs to understand is how to render the domain-meaningless interface.
GrahamS
May '08
@D: “Correct” HTML is view independent. It should “Model” the document text and structure of the document (e.g. this is a top-level heading, this is a sub-heading, this is a paragraph, emphasise this text, etc) but should not dictate how the document is actually presented (e.g. big bold Times heading, 10pt gap after each paragraph) as that is the job of the CSS “View”. That is why elements like FONT, I, and B are deprecated in modern HTML and is why people get worked up about “tables for layout”. As both of these break the model pattern.
David_W
May '08
Stop sweating it! MVC is simply a label on what good programmers have been doing for decades. All it states is that your data (including how you read and write your data) is separate from your logic, and how you display the results is separate from the rest of your code. That’s it. Nothing more to it. For example, let’s say you have a program that reads data from a database and produces a text report. Something a bit more complex than simple SQL statements. Now, imagine what would happen if your data source was changed. What if the database was completely refactored? How much of your program would you have to change? If you kept your data (model) separate from your business logic (code), the damage would be very limited. What if you were told that you’d now have to produce not just the report, but an XML file? Again, if your output (view) was separate from your logic and data, generating the XML output should be very straight forward. The only real difference is that there are dozens of MVC frameworks out there. I always suggest that people take a quick look at Rails to understand MVC. With in 30 minutes of reviewing the web tutorial, you’ll get an excellent understanding how a good framework can help you write MVC style development.
deif
May '08
From a desktop application point of view I’d rather group html+css as the model, the rendering engine (gecko i.e.) the view and the navigator (user input, javascript interpreter, etc…) as the controller.
DanielL
May '08
I personally never quite understood the difference between the controller and view. The view has to create buttons and stuff that the controller needs to update the model so how can those be separate?
LKM
May '08
Would be a nice post, if you hadn’t misunderstood (or misrepresented) MVC. It has nothing to do with whether your application is skinnable (or “skinnable”) - I’m pretty sure most skinnable applications don’t use MVC correctly - and the HTML-CSS-Browser example is, as “experienced architecture astronaut” wrote, certainly not MVC. Perhaps the case could be made that HTML is the model, but CSS the view? That’s where your analogy jumped the shark.
NeilM
May '08
Now, I’m not currently a .NET developer, but a ColdFusion one, and have been looking at ASP.NET MVC with great interest only this morning. In the CF world, nearly every framework out there is MVC and it’s what I’ve been used to for around eight years or so. So much, in fact, that the traditional idea of one aspx file per page seemed a little backward - which previously put me off ASP.NET ASP.NET MVC is definitely a step in the right direction, and the implementation seems nice and clean and simple - I will definitely be taking a closer look at ASP.NET now.
Scott
May '08
I think that I understand MVC, but my problem with MVC (and all patterns in general) is that I don’t understand how to implement them. I want to learn how to do things myself without using frameworks so that I can fully understand how they work.
rich3
May '08
Personally, I get tired of all the arguments about whether a given architecture is really MVC - but HTMLCSS-Browser ain’t MVC. Get a clue.
John_Meyer
May '08
Jeff, Interesting analogy, and quite a bit different from the one I usually use. In my mind, the View is the interface between the app and the user, the Model is the interface between the app and its data (web services, DB, whatever), and the Controller is the traffic cop. I would also take the middle part of that analogy 1 step further to say that if you’re accessing your back end from anywhere other than a Model, you’ve broken the pattern.
MichaelP
May '08
“only the controller is responsible for poking the model data through the … view”? But I thought that the view had to ask questions and send messages. It has to speak the language of the model. If that’s so, then the controller should make introductions and get out of the way. What you just described is Model View Presenter.
Zeroth
May '08
@Daniel Lehman: Think of it this way: the buttons are generic ways to update the model. Imagine, instead, there is only one field. When you type into that field, the field sends that data to the controller. The controller should be separated from the views, in that the controller can take any set of valid data, no matter how its inputted, from a file, from the user, or just plain random dice rolls, and do something with it; be that call a view with the data, or update the database. If you cannot send data to your controller via any set of methods, ie a file vs a form, then its not separated well enough.
SteveS
May '08
“Also in the case of web apps, we cannot seperate logic from presentation completely.” This is not true. There exist a large number of JavaScript application frameworks (for example, Ext at http://extjs.com) which let you build apps using JavaScript, and relying on AJAX for data calls. A company I worked at previously serialized the data from the DB into XML/JSON, which was then loaded by the client and used to populate views. In this sense, JavaScript is powering the Model (data storage and transport), the View (UI components being generated from DOM elements, and not HTML), and the Controller, and the backend is being used as a glorified database gateway (obviously with some security and data sanity checks). This frees up server resources, because we can put a significant amount of processing onto the client. It also means we could write web apps like desktop MVC applications. To me, this class of web applications is far more interesting and fun to write.
Alex
May '08
Those descriptions of MVC were sort of fascinating in terms of language used- The same way you’ll notice people whose first language isn’t english refer to “codes” instead of code, I noticed that the description completely flipped user input / user output, relative to the way I’m used to hearing them (Not claiming anyone is right/wrong, just noticing the differences in how it’s used)He used “User Output” to describe data going FROM the user TO the machine (which would be output from the user) I tend to hear “User Input” used that way… Ditto his use of “User Input” to mean graphs presented to the user.
stonehat
May '08
It [the View] may also update the model by sending appropriate messages. Doesn’t the Controller do that?
Nikes
May '08
Jeff: I’m glad to see some code in your blog again, I’ve no problem with home theaters, energy saving, multiplecore and Gps but man, we are developers. The MVC and MVP patterns are a great arquitecture solutions but I’m totally agree with this. “Personally, I get tired of all the arguments about whether a given architecture is really MVC - but HTMLCSS-Browser ain’t MVC. Get a clue.” Good luck with stackoverflow Jeff, keep blogging!
Nikes
May '08
Jeff: I’m glad to see some code in your blog again, I’ve no problem with home theaters, energy saving, multiplecore and Gps but man, we are developers. The MVC and MVP patterns are a great arquitecture solutions but I’m totally agree with this. “Personally, I get tired of all the arguments about whether a given architecture is really MVC - but HTMLCSS-Browser ain’t MVC. Get a clue.” Good luck with stackoverflow Jeff, keep blogging!
IanP
May '08
My only issue is that in the ASP.NET world is that MVC-ish approaches have been available for a long, long time. It took more work and there were obstacles in the Webforms model that required work-arounds, but it was possible. If your only goal is “separation of concerns” you should have been doing that all along, even back to VBscript classic ASP days. I have been following Hanselman, Haack, and Conery since the first bits were made available to the community of ASP.NET MVC and while I love what I am seeing, I still can’t shake this feeling its really targeting people that never got a handle on the post-back model or controlling their viewstate. Am I being too pragmatic by stating, who does this really serve? Because my users do not care if I employ “Model-View-Presenter” or “MVC”.
Ferdy
May '08
There seems to be many interpretations of how MVC works for web apps, but I think the one discussed by Jeff is definitely not common, and possibly wrong. Here’s how I see it:
Model domain + data access, typically implemented in back-end classes using a middleware platform like ASP.NET, PHP, J2EE and such
View In the case of a web app, this is typically the combination of HTML + CSS, and sometimes even Javascript (for things like pulldown menus). HTML is NOT a model, it is part of the VIEW.
Controller In a web app these are typically the “clicks” in the application. The controller validates input, sends messages to the model and routes the view to the next page I guess there are multiple ways to look at it, but the one above is what I see most in the industry. Seeing HTML as the model is by far the weirdest interpretation of MVC I have ever heard of.
Steve
May '08
I think the development world keeps trying to come up with the best patterns, which it should. Unfortunately, the pre-MVC ASP.NET world relies heavily on the FORM and postbacks, and there is often little “separation of concerns” in these type of web apps. Can/should all apps be made using MVC? No. Is “separation of concerns” (beginning to detest this phrase already) a great idea, is having one place to change something the right way, etc.? Of course. A point to keep in mind is that in order to do “.NET MVC” you will have to abandon the FORM/postback “model”.
Steve
May '08
I think the development world keeps trying to come up with the best patterns, which it should. Unfortunately, the pre-MVC ASP.NET world relies heavily on the FORM and postbacks, and there is often little “separation of concerns” in these type of web apps. Can/should all apps be made using MVC? No. Is “separation of concerns” (beginning to detest this phrase already) a great idea, is having one place to change something the right way, etc.? Of course. A point to keep in mind is that in order to do “.NET MVC” you will have to abandon the FORM/postback “model”.
SeanP
May '08
Jeff, I think your next post should be MVC vs. “3 Tier” in web apps, since I think this is where a lot of the discussion is going. I remember reading up on the MVC model early on and trying to figure out how to merge that into my web apps and became a bit confused on how it would actually flesh out. I think the biggest issue arises at that boundary where the web form is updating it’s display based on a certain data column being set to true/false, or where the custom formatting of a GridView would go. I took to the Presentation / Business Logic Layer / Data Access Layer and it had drastically improved my web apps for maintainability. I still wonder how things get retooled in the ASP.NET MVC model and what would be the pro/con of doing so.
WesternI
May '08
Skinnability is a pretty superficial sort of view customization. It’s no stretch to imagine a system that would be skinnable and still not have proper separation of concerns; indeed, I would guess that many web apps qualify. Just beacause you can juggle fonts with CSS doesn’t mean that mixing and matching different chunks of data on one page comes easily. Separation of concerns is important, but I don’t see the point in attempting to coerce existing systems into a model. Why not just look for the separation of concerns instead? Because there’s more than one way to break up a web app to the the MVC model. In fact, in something like a blog, I think one could make a case that the database is the model, the HTML/CSS/browser is the view, and the scripts on both the server and the web pages are the controller. But what does that prove? What does it mean? How is that observation useful? The main use I can see is that the view and controller are broken up into multiple disparate pieces and are consequently a huge pain to deal with. That is to say, web applications do not follow a clean pattern, aren’t particularly well-designed, and that they’ve succeeded in spite of that, or because they have other advantages.
GrahamS
May '08
“but HTML-CSS-Browser ain’t MVC. Get a clue.” “Seeing HTML as the model is by far the weirdest interpretation of MVC I have ever heard of.” I’m not sure why Jeff is taking such a beating here. I think there may be some misunderstanding. He describes HTML+CSS+Browser as an example of the MVC pattern in action. To my mind he is entirely right. They certainly fit fairly well with the definitions given by Trygve in the article. The entire point of CSS is the separation of data (model) and presentation (view). But importantly (I think) he is talking here about how the components that make up a SINGLE web page conceptually fit together. He is NOT saying that this is how MVC applies to the architecture of your ASP .NET web application. That is a completely different of level of abstraction. In fact when he does mention web apps later in the article he says that in ASP. NET the HTML is part of the View.
CKoz
May '08
Another way to look at what you are saying is to keep your business objects out of your presentation layer. This is a hugely important concept as it allows your code to be highly portable, and you dont have to start from scratch every time there is a ‘latestgreatest Upgrade’. I am a .NET developer and we use CSLA which seems to completely follow this logic. I really appreciate the ability to write new GUI’s with so little code after the first time. And to Shmork You would be surprized to see how well this concept works with .NET3.5 combining the power of Visual studio for a Developer and ExpressionBlend/Illustrator/Photoshop/Quark for the designer. The power of a presentation layer separate from the Business Objects allows the UI to be done in XAML and gives the developer one view while the designer and the rest of the world get a very pretty finished look.
SeanP
May '08
Not to try and cross advertise here or anything, but is there any coincidence that this post comes the same day that Phil Haack is being interviewed on .Net Rocks about the MVC? I’m off to listen!!! Need more input!
chris37
May '08
To those saying that XHTML/CSS/Browser isn’t model/view/controller: I argue that it is MVC. The XHTML is the model, in that it contains the data you need to transform to display to the user(content of XHTML tags), and business-logic(the tags themselves). The XHTML is view-agnostic - you could use a view other than CSS to transform it into a readable format, for example, an XSLT stylesheet could be your view. The CSS is your view in this example - it contains information about how to get what’s in the model into a human-understandable format. It contains no actual business logic or data, it’s solely presentational. The browser is the controller in that it facilitates communication between the model and its various views. It’s definitely not a standard example of MVC, but if you think about it, it does hold. The instant you bring a server-side language into the problem it becomes more complicated and brings you closer to the typical example of MVC.
gemils
May '08
I find it interesting that, for one who proves again and again the simplicity of linking to other web sites and pages in the context of a blog post, there is no proper link to www.csszengarden.com. Screen shots of address bars just aren’t quite the same. Love your site, love your posts, and hope that folks unfamiliar with csszengarden take a look at it.
JonathanH
May '08
Most of the people who are misunderstanding Jeff’s post here are thinking strictly in what they think ‘MVC’ is. That is, a web application framework ala rails,cakephp,django etc. MVC is much more than that. It is a design pattern that goes beyond one architecture. For example, MVC can be applied to a windowing file system: Model: A file. Controller: Ways to apply different actions to the file. View: Could be anything, the view could be the icon to the file, or the file name, or even the files contents. Its not just web frameworks kids
RoshanB
May '08
Thanks a lot for this post…I was really not so clear about the concept of MVC before
David_W
May '08
What MVC tells you is that your data, logic, and how you present the two to the user should not be tied so tightly together that changing one means changing everything else in your program. Remember, MVC is just a good idea, and not the law. My criteria is: Does following whatever model help clarify what you’re programming and makes it easier to maintain? If not, I’ll break that particular model – whether OOP or MVC. The whole purpose of a model should be to make your program better, easier to understand, and easier to maintain. Then again, you shouldn’t break a model just because you’re in a hurry or lazy. Whatever programming you’re doing has to be maintainable. One day, you’ll have to modify the logic, change the way the data is handled, or change the way it is presented.
JustinM
May '08
You can do MVC with web apps, check out JavaScriptMVC.com.
Ferdy
May '08
I still don’t agree with the case of a web page that HTML is the model and CSS the view. This may work for displaying data, but what about data input? CSS being the view cannot really model input forms. Sure, it can style it, but not really model it. This means that your input forms (order of fields, field types, labels, etc) are likely to be part of your HTML, and not the CSS. Thus, the presentation of the input form is mixed with the model, being HTML in the example.
Sam_Galope
May '08
I believe that what you said about “skinnability” is true. Thanks for posting this wonderful article.
Right_On
May '08
What a freak!
Fabrice
May '08
But the first step to harnessing MVC is to understand why it works, I’d love to see an other article about WHY it works. I’m using MVC for my site but I often wonder whether so-and-so should be a simple include, a class, an object, etc. Are all objects called “models” in MVC? What do I do with my “includes”? What’s a model without data? Does MVC allow includes or “libraries”? Can you have a model without a view? etc. I still find it confusing somehow.
StevenR
May '08
Well spoken, Jeff. Asking yourself whether your application is skinnable is a good way to look at MVC.
Sam
May '08
“My favorite thing about CSS is that you can turn it off. All those news sites with tiny text and layouts that break when you size it up? Boom, disable CSS. All those sites locked to 700 pixels wide on my 1920 pixel width monitor? Again, no way I’m using that CSS.” What is the obsession with wide-screen? It is much more efficient to read thin columns that are “tall” than reading very wide columns that are short.
Beck
May '08
There are two different examples of MVC presented in the above article: 1. Web content 2. Three-tier web development So ,just from another point of web content and a AJAX view , without web brower, as HTML+CSS+JavaScript pattern is so popular, I think JavaScript should be the controller of web content.
Nikos
May '08
Languages such as Python or Tcl, use Tkinter(Tk) Graphical User Interface, which hides MVC from the user. If for example you bind a variable x with a button, then whenever you modify x, button’s text will also change. “No need to pass pointers around, to unknown levels up and down”
Venkman
May '08
Jeff: “Isn’t CSS used to do exactly this on the underlying HTML?” Yes, CSS is used to generate the view, but, alas, is not the view itself. The problem I see with this example is that HTML/CSS/Browser can be considered as a “separation of concerns” pattern alright, but it does not actually map to Model-View-Controller. The View in this case is something closer to what the browser temporarily stores as “rendered page cache”. That is the view: the final rendered page. The Model could be both HTML and CSS, and even Javascript in this case is part of what the browser has to render/execute. The Browser is not exactly a Controller either, it doesn’t recieve the input to “operate on the model”, it doesn’t change the HTML if I click on an image in the rendered view of that page. But the underlying error in all this, in my most humble opinion, is trying to force everything into a certain pattern.
MattL
May '08
I never thought much of the the MVC pattern. It’s abstract - too abstract, in fact. If a bunch of smart people can’t agree on what it means then I question the usefulness of it at all. Really brilliant ideas make you say, “Why didn’t I think of that?”. The most common reaction to MVC is, “Huh?”
kris3
May '08
If you think about it, ASP.NET by itself is already (and has been from the start) MVC complient, you have View (.aspx), Controller (aspx.cs) and Model (whatever backend). The only problem being ASP.NET makes it easy to do View and even Model stuff in what should really be the Controller. I haven’t really dug into the newish MVC framework yet, but it what i’ve seen does look cool, more tightly defined seperation of concepts etc. so it looks like it’ll make it easier to write leaner, cleaner code. Definately not a bad thing.
Jax
May '08
I disagree with these examples. The model is always a fat Albanian goat named Morris, the view should be a softly baked piece of brie placed on a wooden shelf on an autumn afternoon and the controller should be the echos of a Chas and Dave anthem played at full volume (11) through crackily speakers. Everyone else is just wrong because I know better.
Jim_Cooper
May '08
I dunno, forcing the MVC pattern over HTML/CSS/browser seems a stretch to me. That is view/other bit of view/bit that displays the view, IMO. And I don’t think “different levels of abstraction” come into it either. It seems a bit like when you have a hammer… That said, the more interest generated in patterns the better. I struggled for years at programming conferences to get people to look at things beyond the trivial “how to use component/framework X” type sessions. Take a look at MS Tech-Ed sessions and see how often such things are discussed, for example.
GrahamS
May '08
@Venkman: Yes, CSS is used to generate the view, but, alas, is not the view itself. The View in this case is something closer to what the browser temporarily stores as “rendered page cache”. I don’t agree. It isn’t meant to be taken that literally. The View is the “presentation filter” that determines how the model is presented to the user. That is what the CSS does. If you argue that the View is literally the thing you see then why stop at the “rendered page cache”? By that logic you could argue that the view is the Windows drawing area or the frame buffer in the video card.
Danny
May '08
MVC works ok for traditional content-oriented web apps (with Plain Old Semantic HTML), but works better still generalised data-oriented web-apps: Semantic Web apps could I suppose appear as a subtree under any of these - M for inference engines and the like; V for user-oriented apps; C for services/autonomous agents see also: http://en.wikipedia.org/wiki/Linked_Data
matt23
May '08
I think for a bunch of people reading a programming blog many of you fail to see the abstraction that Jeff is trying to point out and instead are concentrating on the example he uses to try and convey that abstraction. MVC is not a concrete implementation but an idea that you should separate, as much as possible, the logic that makes up those ideas of model, view and controller. Depending on what level of abstraction you think of Jeff’s HTML+CSS+Browser example in it can either make perfect sense or none at all. Don’t forget, it is software, we make up the rules as we go along and there is no such thing as the right answer.
GrahamS
May '08
HTML/CSS/browser seems a stretch to me. That is view/other bit of view/bit that displays the view HTML is definitely the Model. HTML is purely intended to describe (model) the structure of a document. It does not determine HOW the document looks. It only describes the document’s contents and structure. e.g. h1Header/h1 pA paragraph./p just describes a headline and a paragraph of text. It doesn’t say the header should be large or bold, or that the paragraph should have a space above or below it. CSS is definitely the View. It has knowledge of the HTML (model) it is presenting and provides details of how it should be presented. The same HTML model can be presented in completely different ways by two different CSS views. Browser could be viewed as the Controller. Not a great fit, since the browser typically responds to the user clicking links by requesting a new model from the server, rather passing messages onto the View. But it does fit with the “the link between a user and the system” – The point of patterns like this is to aid understanding. “A software metaphor is more like a searchlight than a road map” as Steve McConnell says. I find it useful and illuminating to think of the interaction of HTML/CSS/Browser as an example of MVC. So the metaphor works for me.
YoniR
May '08
I have a problem with some uses of MVC. Namely finding triplets such as: Order, OrderView, OrderController etc… If I take your web framework analogy, it is like having every web page have its own HTML, CSS and browser(!). When, in fact, it is only the model that has to change while the view and controller is reused across models.
Stelios
May '08
Very informative … got some details, helpful for someone that has an exam in 1 hour … concerning MVC amongst other thinks.
Jax
May '08
Wow this disucssion is a classic “WTF is MVC” discussion. I work a few contracts and by jove have I seen some interesting implementations of MVC so i’m not suprised that people have such differing opinions. I personally think the example Jeff gives is a good one and am glad that someone is finally giving good examples like this instead of binding it to a particular technology or particular way of doing things. I think it is more logical to agree on the principle of Separation of Concerns and allow the MVC pattern to evolve naturally as opposed to religeously following one implementation of MVC. Same goes for MVP, it’s just MVC with a slight difference and Presenter is a bad word for a controller (which might also write a file to disk which has nothing to do with “presenting”) so instead of making different words for slightly different MVCs lets just talk SoC from now on!
HansB
May '08
A MVC masturbation article? What is this 2005? Can we please be spared by the ensuing RoR is great article?
Martin
May '08
Cheers. Finally, I think I’ve grasped it.
Jim_Cooper
May '08
CSS is definitely the View Well, if you make HTML the model, then CSS is also part of that model, IMO. CSS does not do anything to HTML in and of itself. That job is done by the rendering engine. CSS is extra information that it uses. So if you’re using MVC to write the rendering engine, both the HTML and the CSS are in the Model. If either changes then the View (eg the display in the browser) has to change. I find it useful and illuminating to think of the interaction of HTML/CSS/Browser as an example of MVC I find it confuses the issue, because it’s not an example of MVC There would not be this disagreement if it was a good example.
Continue Discussion 27 more replies
I think there are far clearer examples.