Thursday, December 22. 2005Why MVC works for Web Applications
I am writing this in response to Harry Fuecks - MVC and web apps: oil and water post on Sitepoint. Let me first say, that I have yet to have a product make it to production that follows strict MVC, however the pattern is becoming a strong feature in our application design process. The largest stickler with MVC, is seperations of Data and Presentation. This is remarkably similar to the current web standards push of seperating Semantic Markup (Data) and Design (Presentation) through the use of CSS-P. This is, I believe another small part of why MVC is seeing much more hype lately. Go look at a lot of Ruby on Rails websites, see how many are using CSS in abundance? However, there are other reasons. I am now looking to re-write a large application, and MVC is becoming more and more tempting. The reason for this is that with the web evolving as it is, we need to ensure data integrity beyond handling form submissions. We are now needing to serve the same data, and allow the same backend processes to happen through multiple means. There is the standard "Database -> PHP -> HTML (via a template) -> Browser -> Client -> Form -> Server -> PHP -> Database" workflow and in addition there are new workflows like these (highly simplified!): Web Services"Database -> PHP -> (SOAP|REST|XML-RPC) XML (via a template, albeit it usually a code toolkit usually) -> Soap Client -> Response -> Server -> PHP -> Database" RSS"Database -> PHP -> (RSS|RDF|ATOM) XML (via a template) -> RSS Reader" AJAX"Database -> PHP -> HTML (via template) -> Browser -> Client -> Web Control (link, form) -> Server -> PHP -> Database -> (XML|JSON|HTML|Plain Text) via template -> Browser -> Client -> .... " Note: All of these denote the linear order of events, its not meant to replace a nice UML Workflow diagram or some such Therefore, with all these access methods, it is my view, that Data Integrity is the single most important part of a web application. Be that integrity in the database, or integrity in getting it to the client correctly. Everything else in between doesn't matter in the grand scheme of things. Therefore, having a rigid set of Model (Data Manipulation and Retrieval), View (Generating HTML, XML, SOAP, XML-RPC, REST, RSS, RDF, ATOM, JSON, Plain Text) and Controller (Handling Web Service, RSS, AJAX and standard browser requests) does suddenly seem like a great way to plan for adding methods of handling new client data retrieval techniques without futzing with every aspect of your application (what happens when SOAP 2 is released? or a new feed format? Adding support for these should not impact any other "View" of your application) - Davey Comments
Display comments as
(Linear | Threaded)
When do I get the spiffy uniform and lightsaber?
- Davey
It's interesting that this could even be an issue...
I've used Apache Struts and Hibernate on several projects now and I would never develop a significant application in anything else! It's use of MVC is stunning. For instance, I can at the drop of a hat cluster my database and 2 days later decide to switch database all together and use a text file, it's that easy! But MVC doesn't stop at database abstraction. The controller and view are important separations also. Another example would be; in a system, I'm able to use the exact same controller class(es) to send data to a WML, PDF, HTML, etc version of a news summary page. All I have to do is change the view. Since the controller always outputs the same data, I'm simply able to add a new 'view' to manipulate that data into whatever format I wish.
But here's a teaser - do you require MVC to have your seperations? Is there any other pattern that might fit using the same sort of seperations? There are other similar patterns around, such as model view presenter: http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
I'm not arguing against seperations - just asking if MVC in particular is the right pattern to have adopted got web applications.
Model View Presenter seems to require a presentation layer (i.e. to *display* the data and controls for handling it), this seems to not quite fit when Web Services come in to play.
Admittedly, I didn't do much more than scan the page for a few minutes, so I will review again later when I have more time  - Davey
Note also I'm not saying Model View Presenter is appropriate for the web (just a random pattern which serves a similar kind of purpose to MVC) - just there may be alternative patterns to MVC which have a better fit for the web,
The article that got me started "Beyond MVC": http://today.java.net/pub/a/today/2003/12/11/mvc.html - talks about an alternative at the end. Interesting what it seems to be suggesting looks like what people like ActiveGrid are doing (ties into the whole SOA buzz) - something like "workflows and services". I need to time to expand and research further which I don't have but the direction that path seems to be going in is seperate your "forms engine" (which might be server side or client side) from your resources / services. Perhaps what I'm really trying to get to is something about how frameworks need to make a distinction between "resources" in the HTTP / REST sense where "actions" should be restricted to HTTP methods, placing less emphasis on the Controller, and form processing / UI stuff where there might be a large vocabulary of actions (AddToCart, RemoveFromCart etc.). Anyway - enough already. |
About Me
Davey Shafik is a full time PHP Developer with 7-10 years experience in PHP and related technologies. An avid magazine writer and soon to be book author, Davey keeps his mind sharp by trying to tackle problems from a unique perspective.
ConferencesNone at this time! Calendar
QuicksearchTagsArchivesSyndicate This BlogBlog Administration |
|||||||||||||||||||||||||||||||||||||||||||||||||
Harry Fuecks' made some interesting observations on the Model-View-Controller (MVC) pattern of application development as it applies to Web applications in a very long post called MVC and web apps: oil and water: What I’m really trying to say here is
Tracked: Dec 22, 13:42