From Wikipedia, it looks that MVC helps long term coding development. I'm not very sure if MVC can make a significant difference with long term web development.

But, when upgrading versions, the users have to wait modules of new version for a long time. It seems often that modules of previous version can not move forward within a short time with the core program. The time lag creates hesitation to use present version and the new version. Isn't it a waste?

My questions are:
1. if Drupal support a MVC framework?
2. from where I can find relative information?

Comments

styro’s picture

but Drupal is split into relatively independent layers the similar to the way MVC apps are split into layers. There is nothing inherently magical or special about MVC - there are plenty of other design patterns that acheive the same benefits.

This might help:
http://api.drupal.org/api/HEAD/file/developer/topics/oop.html

But MVC or other design has nothing to do with upgrade compatibility though.

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

WJ’s picture

It's getting more confused when comparing yours and this blog, http://archivemati.ca/2006/01/21/drupal-as-a-mvc-framework/.

How do you comment this blog?

styro’s picture

Here's one from Larry:
http://www.garfieldtech.com/blog/mvc-vs-pac

I'm definitely no MVC guru (in fact nearly the opposite), but the MVC pattern actually has a fairly detailed definition and was originally developed for GUI apps back in the Smalltalk days at Xerox PARC. It was Sun (I think) that tried to twist the idea into web apps (MVC model 2 or something?). And this form of MVC on the web was popularised by Struts in Java but it was pretty cumbersome by all accounts.

The blog posting you linked to was very interesting and well written (I've only quickly skimmed it), but I think the writer was thinking more along the lines of comparing Drupal to an MVC design and as an intellectual exercise trying to fit the relevant bits into the appropriate layers. There is lots of cool discussion in the comments - I'll have to read it in more detail later :)

Sure if you use a vague definition of MVC and squint a bit, Drupal can look like an MVC architecture because it does has have rough separations along those lines (eg database, modules, themes). But each layers responsibilities and the way each layer communicates with the others don't really match MVC. eg in Drupal the 'controller' layer (eg modules) does most of what the Model and View layers do in MVC.

I suspect most of the new style MVC web frameworks are only nominally MVC anyway - although they are much closer than Drupal. Web frameworks seem to work best when as much view logic as possible is moved elsewhere - ie modern web frameworks prefer (rightly so IMO) their views to be even thinner/dumber than traditional MVC views.

There are plenty of other subtly different designs with 3 letter acronyms eg Model View Presenter etc and no doubt a lot are better suited to web apps. MVC is nothing magical in itself - it's just one valid design pattern out of many. Just because a design has 3 component layers doesn't make it MVC.

Anyway, that was just my semi informed comments. Others would probably have better responses :)

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

styro’s picture

Most important thing - don't get too caught up in this design patterns stuff. While a general understanding is good - when taking it too far it all just becomes pointless abstraction and pedantry. Just start building stuff :)

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

shanavas’s picture

Then what is the advantage of MVC in other framework like ROR

styro’s picture

The "ends" you want are things like separation of concerns, easy development, easy maintenance, easy extensibility etc. MVC is just one architecture that aims to achieve those ends. There are plenty of other architectures that also achieve those ends.

Choosing a platform on the basis of MVC vs something else is silly - choose a platform based on the benefits it gives you rather than the way it is laid out. There are possibly as many MVC platforms that are a pain to work with as there are ones that are great to work with.

eg Struts, MFC, Qt, Swing etc are all based on MVC but are very different from Rails. The innovation and power of something like Rails doesn't come from MVC, but the new approaches it took to automating the drudgery of web development.

Rails power comes from making the developer very productive by doing a lot with small amounts high-level code, whereas Drupal aims to let the developer be very productive by allowing them to easily integrate the work of others in a very pluggable system. MVC in Rails separates out the development roles within a team really well, but I think Drupals modular architecture is a better design for reusing shared code from sources outside your team.

Rails is better suited for making focussed web applications, and Drupal is better suited for making extensible user driven web sites and online communities. Choosing Drupal or Rails depends on what you need to do. They aren't exactly intended for the same things even if there is some areas they could both be used for. eg you could use even use Rails to build a Drupal like system.

--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal

peterx’s picture

Model-view-controller (MVC) architecture is optional in Drupal. MVC is accomplished by generating data in modules then theming the data in your theme.

Some modules format the data before output, which is not MVC.

Some modules format the output and provide documentation in how to reformat the data in your theme, which is MVO, Model-view-optional.

The best modules structure the output data using only classes and ids. They provide documentation on how to apply formatting using theme functions and CSS in your theme. They pass all output through t() to translate text and theme() to apply themeing. They supply a default CSS file so your data looks ok until you get around to developing your own theme. They are pure MVC.

When you use Drupal and find the odd bit of data that is not easily themed, there is an easy way to request a change to the relevant module. The module can be updated to theme the data in the standard way.

MVC is also used to describe a highly stylized way of writing code in Java. You can write code the same way in PHP 5. Java does not have the native associative arrays that are available on PHP, which means Java programmers have to emulate associative arrays using collections of objects. PHP offers far easier and more efficient ways to write the same code without sitting through a couple of years of programming theory at university. For those who did sit through several years of programming theory at university and went over to the dark side, you can use the MVC stylized code approach within Drupal modules using the objected oriented coding in PHP 5.

petermoulding.com/web_architect

Jeff Veit’s picture

I don't count myself as an MVC expert, but I have written a few MVC frameworks for general software & web apps.

I've come to the conclusion that usually MVC is not appropriate for web apps.

There are several reasons:
1. MVC is not actually terribly well defined. It's certainly evolved since the original definition, 20 odd years ago. That's because it wasn't as suitable when applied more generally. More modern versions have moved away from the traditional MVC separation to something that is more Model-PresentationController. That's because the View is usually very closely tied to the controller.

2. A big benefit of traditional MVC is the ability to show the same info in two different formats: as a graph and table. Actually, most web software does not do this. It only displays info in the form originally used.

3. MVC is complex. But the complexity doesn't add to managability for web apps, in my experience. Other's mileage may vary. Lots of overhead for not a lot of benefit.

One of the things I like about Drupal is that it is well designed. While it's not MVC, there is usually separation between the computation and the presentation. It's always possible to increase this, but at the risk of lower performance.

peterx’s picture

How do you differenciate between view and presentation?

Something you can do with Web sites and CSS is to format output for different purposes including print, WAP, etc. I can see how you call that presentation because you change only the presentation but future versions of CSS are moving toward programming facilities to let you change the structure and sequence of data. Will that be still only presentation?

At the code level you have programs such as phpMyAdmin exporting data in different formats for display on screen or delivery to a file. I created a number of systems that optionally feed Excel, deliver PDF, and create graphs. When is it view or presentation?

There are the Drupal facilities to deliver data as RSS and there is the facility to deliver a node body or a teaser. When do these become views?

When you deliver XML, the visitor can change the presentation and the view in the browser, which moves presentation and view activity from the server to the client. Would a site be reduced to MC?

Most Drupal site owners do not change views through code, they work on the presentation in the theme. Their choice of modules often changes the view and some modules dynamically change the view based on the date, user, permissions and other factors, which moves from presentation to view.

petermoulding.com/web_architect

WJ’s picture

From collected views here and my amateur judgment, I am inclined to reach an agreement that MVC is not very suitable for the web applications. (because http://www.zend.com/products/zend_core, where the Zend framework (MVC) is embedded in Zend Core, which is mainly designed for enterprise systems like for IBM and Oracle.)

But, from http://www.zend.com/products/zend_core/features, it features Zend Framework (MVC) as for Web 2.0 applications. The conflicts raise a confusion against why the web applications are not prioritized. And, I know it's not the way to judge.

This winding discussions may go on because we're not from Zend nor Drupal. And, we may take an elephant's nose as a trunk.

Back to my original concern and question, I assumed MVC may offer better management and flexibility to long-term software development. If Drupal has MVC architecture, it should be easier for everyone, including programmers and users, to upgrade from version to version without spanning a long time waiting modules of previous version to be upgraded. This was what I concerned about if Drupal has MVC architecture. And, could also be a factor in choosing CMS. If it is not, then I learn something.

Maybe, someone from Drupal team should come up and give a formal answer to this question.

Or, someone may guide me where to post such questions to get Drupal's attention.

peterx’s picture

Minor updates do not change the data, the model, which means views and everything else can continue to work. When you make a major change, you change the model which means a view may continue to work but not show new data.

As an example of what works, some 4.7 modules install easily, by hand, in 5.0. They cannot use the 5.0 automatic install features because that was not in the 4.7 model.

As an example of what does not work, some 4.7 modules cannot be installed in 5.0 without modification because 5.0 changes the administration settings module. The administration part of the model changed which means your views of settings need to change. The modules have to change their part of the MVC structure to match the core part.

Think of MVC as three components with APIs, Application Programming Interfaces, in between. If you change only the content flowing through the APIs, the components can continue to work independently. If you change the structure of the APIs, the components may have to change to use the new structure, depending on which parts of the data they need.

All the modules need matching changes if they use the changed parts. Many modules have administration settings which means they need that part changed to go from 4.7 to 5.0.

5.0 changed the API from model to controller but not to the view/presentation part which is why themes continued working with little change.

One change that will reduce future changes is moving information out of module code and into the .info file. That effectively moves some model processing out of modules and back into core. If Drupal 6.0 changed all the administration settings to parameters in .info then in future releases of Drupal the administration settings model could change without having to change the modules because all of the settings part of the model would be in the core.

To make a change as revolutionary as that, you would have to make a one off change to part of the model that is replicated in each module which means all the modules would have to change.

Modules replicate the MVC of core Drupal which means a change to part of the core M or V or C needs a corresponding change to the M or V or C of a module if the module implements the same part. If you are willing to increase CPU usage to reduce future changes then you move the processing from the modules back into the core and change the modules to provide parameters, along the lines of the .info file, for interpretation by Drupal.

Centralizing the M or the V or the C in Drupal core both increases processing overhead and immediately limits the functionality of a module to whatever can be interpreted by Drupal core. Some other CMSs do exactly that and I replace a lot of those other CMSs with more flexible CMSs as soon as a Web site owner hits a limitation of a centralized system.

The module update delay is not related to MVC or not MVC, it is related to sharing the core processes with the modules. The modules are allowed to enhance the core processing but have to stay locked in step with the core to connect into the core. The modules share the M and have to match the core M to continue sharing.

Themes share the V and continue to work when the M changes. Themes can optionally connect into the M and C but if they do, they have to be updated to match changes to core M and C.

Drupal's modular structure, with code out in the modules, could be equated to changing cars from their current 12 volts to the 24 volts used in trucks. You could make the change to the core car without changing any of the plug in options so long as the plug in options do not use the car's electricity. Your optional rear spoiler would continue to work. Your sound system with the 3000 watt woofer would be fried by the 24 volts.

Having worked with unshared MVC, I prefer shared MVC for the flexibility. I like Drupal's slow movement of added functionality from the modules to the core as that provides stability and minimizes the work to change a module from release to release.

You can discuss view versus presentation forever but the thing holding back the updating of new modules, the shared M and C, is the thing that makes Drupal so flexible and makes the modules powerful.

petermoulding.com/web_architect

g10’s picture

Drupal is not MVC imo, it does a good job in abstracting in general, but is not truly MVC and thus is missing some advantages of MVC dev.

Thinking of MVC as an overall/overstretching approach for Drupal is wrong, the core != model and modules != view... the real use and advantage comes when mixin design patterns at several layers...

Allthought calling eg. node_load() fetches you an object with all the node elements (which adheres 'view calls model'), alot of methods fetch a themed & translated output (mostly the case in modules)... this is fine when solely used with the theming functionality of drupal (and having a html output), but this is where it stops being MVC.

To be truly MVC the theming should implemented in a view, a module should implement its functionality (model) totally seperated from the theming (view). The big advantage to come in play here would be that the model of the module could be developped independently from the view (while now we see duplicated modules simply to be able to implement another view).

Stating that MVC is not appropriate for web dev is plain ignorant (or you like to write the same over and over ;)

as an example we could take a calendar module (speaking of a hypothetical module here), where there is a model (handling the tracking of which month, how many days in month...), and with this model, several views could be implemented… eg. a view that simply shows a monthly calendar as we know it (bunch of days, highlighting several events in the month)… or a view that simply lists the events in that month (not all the days, simply the one with an event)…
As you can see, with the same model, there could be several views. Same goes for every module, eg. a newsletter module could have a model that handles the subscribing/unsubscribing, sending of newsletters… but how it is presented to the user is entirely up to the view, if the view wishes to represent an error, whilst sending, with a string stating 'there is an error…' or by some visual eg. red marker, then this is entirely up to the view... the model should only notify the view of the status, then the view should act upon it accordingly…

So having Drupal truly MVC (and the modules), would yield quite some advantages, on one hand the models and the views could be developped independently (with some controllers along the models, and extending controllers with the views where this is needed), this would give us several views of modules sharing the same model. And, more importantly, the views could be outputting in whichever format you want, going from straight HTML, over AJAX to Flash/Flex (or whatever flavour will come along in the future, ahum, silverlight anyone?)…

after all, the logic to send eg. a mail with php, is same for a simple webform in HTML and a Flash form

NOTE: I am mainly experienced as Flash OOP dev, using Drupal as back-end, which is a great combo (especially with the services module)... allthought stumbled once to much on Drupal not separating the model from the view (or the logic from the presentation as you wish), which is a pity

shanavas’s picture

Is it comparable both Drupal and ROR ?
Is Drupal is based on MVC?
I need to develop a complex web application which one u prefer..?

mfer’s picture

Drupal is a Presentation Abstraction Control architecture. Check out http://www.dossier-andreas.net/software_architecture/pac.html.

For many complicated things this is what you might want over an MVC architecture.

--
Matt
www.mattfarina.com
www.innovatingtomorrow.net
www.geeksandgod.com