What makes a framework a "true" MVC framework?

views:

672

answers:

+12 Q:

What makes a framework a "true" MVC framework?

When reading online discussions about MVC frameworks, I hear a lot of commentary pointed toward PHP projects like Cake, Code Igniter and Symfony from Java/.NET developers in the vein of "those are clever hacks, but not true MVC".

So, what makes something a "true" MVC framework. i.e. what's an example of a .NET or Java MVC framework that does things differently than Cake, Code Igniter, Symfony, etc., and what are those different things? Is it just PHP's lack of a forced object orientation requiring a bootstrap, or is it something else?

I know why PHP the language "sucks", I'm more interested in the differences in MVC implementation and/or use.

JavaServer Faces is a pretty good full stack framework for MVC. It has good View components, good controllers with the managed beans, and for the model you can create business classes.

amischiefr 2009-06-18 18:24:30

I'm less interested in specific framework, and more interested in differences between the PHP frameworks and other frameworks. What makes JavaServer Faces more "true" or "better".

Alan Storm 2009-06-18 18:28:48

+1 A:

You may find this wiki page useful.

McWafflestix 2009-06-18 18:28:26

+7 A:

The idea of MVC is to decouple the application architecture into three independent tiers, and allow each of these tiers to use a different implementation without affecting the other tiers. Mostly the distinction is between business logic (the Model) and presentation (the View).

Many PHP frameworks try to use the Ruby on Rails philosophy of "opinionated software" so the correct functioning of the Model and View together require that both conform to a certain implementation. That is, classes have to be named a certain way, files in the project have to be organized according to a certain directory structure, notation in the View scripts have to follow a convention, etc.

This makes it hard to substitute different implementations of each tier independently, and this is against MVC's objective of decoupling the tiers from one another.

Bill Karwin 2009-06-18 18:40:24

I'm pretty sure the Model, View, and Controller layers in Rails are fairly decoupled. That is, the view doesn't care what base class your models derive from, and your controller doesn't care what View engine you are using, etc. The framework itself uses conventions to glue these things together, but the layers themselves are not really coupled to each other.

Doug R 2009-06-18 18:52:08

Thanks Bill, that's the best answer I've heard so far. One thing I'm not quite following though is "functioning of the Model and View together require that both conform to a certain implementation". The the PHP MVC frameworks I've seen/used, controllers intercept incoming requests, instantiate and call methods on models, and then extract information for display from models and export it to the view. That seems like the view and model are pretty independent, so what am I missing?

Alan Storm 2009-06-18 19:08:56

Many frameworks assume that an URL like "/admin/delete/user/123" corresponds to a controller "admin," an action method "delete," a model named "user" with a primary key named "id," and a view also named "admin/delete" to show the result. The conventions *are* the coupling.

Bill Karwin 2009-06-18 19:28:04

Bill, you keep using this word "coupling". I do not think it means what you think it means. There's always going to be code that ties layers together. This is not coupling. I think what you are thinking of is called "cohesion", which is generally considered to be a desirable trait. The layers work well together (high cohesion), but do not have interdependent implementations (low coupling).

Doug R 2009-06-18 20:49:22

"That would be inconceivable!" :-) But they *do* have interdependent implementations. Changing the name of a Model, for instance, would require changing the URL that accesses that Model, and also changing the names of the Controller and View that employ that Model.

Bill Karwin 2009-06-18 21:20:39

Cohesion, as I understand it, is not about how well the classes work together, it's about how well they encapsulate a related set of responsibilities. If anything, the fact that the implementation of conventions is spread over all layers is a sign of poor cohesion.

Bill Karwin 2009-06-18 21:21:27

You can have controllers in Rails that do not have either models or views associated with them. You can have views that do not have associated controllers. And models are not tied to either. This means the implementation is not interdependent. You can name your controller BlogPost, and your model object Post, and things will work just fine, trust me, because controllers do not just blindly spit out objects. That behavior has to be defined. But by convention, one typically defines that the "show" method for a controller at least returns a model object of the same name as the controller.

Doug R 2009-06-18 21:37:04

+1 to all Princess Bride references :)

Richard Szalay 2009-11-26 17:21:02

Sometimes people need to step back and look at real life "frameworks" from which the digital world got the term from. That might help to explain it's meaning despite endless online options distorting the word to fit personal agendas and belittle other systems.

A framework should help you in every area of your work.

So if you only have a single portfolio page - then you only need a tiny set of tools. If you start the next Facebook then your "framework" will be massively different.

Xeoncross 2009-06-18 22:14:01

All true, but not really what I asked.

Alan Storm 2009-06-18 23:56:10

+1 A:

Cake and most "MVC" frameworks are what you might call a "Passive View" MVC. Here's a great article explaining: http://www.martinfowler.com/eaaDev/PassiveScreen.html

Nolte Burke 2009-06-19 13:56:53

To me, passive view relies more on the discipline of the developer than the design of the framework. It's all too easy, and even encouraged, with most view engines to include logic in the view. For ultimate testability, your view shouldn't be doing things like formatting dates for display; instead, your controller would inject your view model with the formatted date ready to go. That way, you can write tests against the formatted date, which is the one that is actually displayed in your view...

Noah Heldman 2010-02-19 19:34:47

+1 A:

A true MVC framework has no M(odel) layer. CakePHP and friends have some clever classes to access the database, which they call Model, leaving the bulk of data processing to the Controller.

That is wrong. The Model should do all the data processing (and it can use helping database classes for that) and the Controller should be the gateway between the user/webpage and the model. Most of the time, the model is a simple PHP object not adhering to any rules, so the framework can't specify those rules.

Bart van Heukelom 2009-11-26 15:51:58

A framework, as its name implies, is meant to support structures - in this case your application. The common (and sad) thing about most frameworks you'd see floating around is that they become imposing structures themselves, dictating their own way of separating business logic, presentation, routing/control. You'd see application code that looks like you need an entire team just to maintain something you wrote a year ago. It seems like the objective is richness of the features in the framework. No it's not. It's about giving freedom to the programmer to decide for him/herself what components of an application should be separated and where the separation should be - for as long as the the task can be distributed among a work group of individuals with their own expertise.

Whether the separation should be between model, view and control - which by the way have to communicate somehow with each other somewhere - the blur or distinction should be decided upon by the solutions architect.

stillstanding 2010-02-19 19:26:00

It's frameworks all the way down!

Alan Storm 2010-02-19 21:56:30

ansaurus

tags:

views:

answers:

What makes a framework a "true" MVC framework?

related questions