The value of MVC
November 28th, 2004John Lim has a recent rant asking Is MVC over-designed crap?
I used to think so, but now having refactored some existing applications to use MVC, i see the value.
In my unscientific comparison of PHP and Java Job Markets six of ten java jobs ask for some Struts knowledge. While I am willing to believe that Java programmers are masochists, one cannot discount the possibility that there is value in its use.
Another way to approach the issue is to look at this Java framework comparison. It compares the same CRUD application written in Struts, Spring, JSF, Tapestry, and WebWork. The thing that I found striking about the comparison was how “crufty” the struts implementation was in comparison to the others. And yet, none of the others were mentioned in my 10 job sampling. Again, it seems like Struts must bring something to the table.
It is worth remembering that Struts did not originate inside Sun and get pushed out as a bloated vendor standard. Rather it evolved into a de-facto standard of what MVC means on the web as an open source project. I think this growth in use is an indication that web MVC has value.
Is there confusion over MVC?
Yes. Many of the “what goes where” arguments are a bit like trying to count the number of angels that can dance on the head of a pin. In practice, a 100% separations M, V, and C concerns is almost impossible and not even desirable. Yet, it turns out that making some kind of distinction between the concerns is helpful.
Adding to the confusion is the fact that most MVC frameworks do more than just MVC.
I tend to find that the broader your definition of MVC, the more trouble you are going to have with the “what goes where” and “where does this go” questions. In that light, I tried to write up a fairly strict and complete definition of Model View Controller.
I like to use an analogy from the GUI era. If you were writing a GUI application for the Macintosh in 1987, it was hard. Hello World was 50,000 lines long. (at least it seemed like it.) You were responsible for your own event loop and dispatching OS events into your application. Every application re-invented the wheel.
If you are writing a windows GUI application in 1997, you would use a tool like Visual Basic or Delphi to apply the MVC pattern (well really DocumentView variant) to your GUI applications. Both tools take the OS event loop (controller) away from the programmer and dictate an application structure. Trust me, productivity in these environments was leaps and bounds better than the old way. The emergence of Visual Basic and Delphi in the early 90s were just a sign that programmers were getting a handle on how to write GUI applications
I think we are seeing the same transition now in the web application space. Web MVC brings a standard structure to web applications, and in a way, once again takes over the OS event interface for web applications. In 2007, writing a web application without an MVC framework will seem as quaint and be as rare as a polling event loop is today in a GUI application. The emergence of web MVC frameworks is a sign that we as a profession are mastering the art of building web applications.
November 29th, 2004 at 4:05 am
Except it will not come from Stuts : Ruby on Rails is my first clue ! And it probably won’t be called MVC but just “WebApp Framework”.
November 29th, 2004 at 6:30 am
energy follows the path of least resistence. MVC is not that path.
November 29th, 2004 at 8:06 am
I’m fairly new to formalised thinking on design patterns and have been following these discussions as best I can. My only exposure to MVC has been through learning Cocoa (an ongoing process) and I’ve found the use of it there liberating. What I’ve not yet found is a truly compelling demonstration of how to apply MVC to web development or a good articulation of what degree of separation of the different layers “counts” as MVC.
Reading this entry I’m left wondering the extent to which use of IDEs is responsible for the success of design patterns on more traditional platforms. For me, XCode has been my introduction to MVC. Or is it more about layers/libraries that we all use in common (Visual Basic libraries, Cocoa, etc)? If the latter, how close are we to having the required libraries, and should we be looking for something that is PHP-specific or a broader platform that can be utilised from (almost) any language?
November 29th, 2004 at 12:13 pm
Maybe it will be called WACT.
The point that I was trying to make by linking to the Java framework comparison was that it would seem that even a confusing, crufty MVC framework is better than no framework. MVC frameworks in PHP are very immature and behind the state of the art in Java. Struts 1.0 was released in June 2001 and been actively developed far longer than any PHP equivalent.
The path of least resistance is to use an existing, mature MVC framework and NOT to try and implement it yourself. Then, you can stop worrying so much about what goes where and just use the structure and components provided for you. When PHP MVC frameworks are mature, they will be the path of least resistence.
Regarding the impact of IDEs, there is an interesting post making the rounds right now: The IDE divide (language vs IDE).
I am very impressed with Cocoa and Objective C. In many ways, I think that Objective C’s dynamic nature and Cocoa’s maturity make it a better role model for PHP than the younger statically typed java.
December 10th, 2004 at 11:52 am
I started to post a comment, but it got really long, so now it’s here: http://www.askderekscruggs.com/mvc-and-php-fusebox.html
I would’ve posted a trackback but didn’t see a trackback url in your post.
April 23rd, 2008 at 11:40 pm
the MVC i love forever is cakephp
May 5th, 2008 at 7:40 pm
Of course, but what do you think about that?,
September 19th, 2008 at 10:40 pm
MVC or similarly modeled frameworks are the only way to fly when it comes to web development, especially in PHP. However, if you’re looking to actually get serious about decreasing your development time and increasing feature sets with minimal effort, you’ll ditch cake for Fuse.