What makes a framework a "true" MVC framework?

Question

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.

Answer 1

Here are few question that might help you to see if your framework is good and true.

"Can i run unit tests for my MVC classes without framework?"

And this applies even if you don't write unit test.

You should be able to write MVC-related code independently from the framework. When you application receives some input from framework, it should be as objects with known interfaces, no concrete classes.

Thing is, are true MVC framework would have no (or very limited) impact on the architecture itself. At best, it would just provide a clear and easy way for application call to get to your MVC triads. And maybe provide conveniences for You .. not limitations and constraints.

"Does it run on magic and fairy dust?"

You should be able to extend any class, which was provided by framework. And it should be easy to understand which function you must implement.

This becomes very hard to do if "thing just happen". This usually points to global state in the framework's code. Either in form of static methods or global/static variables.

"At which point MY code kicks in?"

Can you find where and how you controller gets executed? Usually it won't be all that easy. That mystical point usually is deep in object-graph. Sometimes even in an extended class.

Such situation makes very hard for you to change the environment, in which the controller was executed. It also imposes strict rules of how your controller methods should look like.

This all brings back to the point, that at true MVC framework should enhance the development process instead of restricting your options.

"Was he/she supposed to be able to do this?"

Authentication an authorization might seem like a separate aspect of development, but actually, in context of MVC, it is has a tendency to be somewhat tricky.

A lot of frameworks have some authentication/authorization infrastructure. This is a repetitive task, and we all have done it to death, thus - it is a good candidate for feature, which framework can provide.

But here's the kicker: most of them try to put the authorization inside your controllers and they are very picky about how it can be tuned. This is another restriction.

What this comes down to is this. For any framework, it must not require to rewrite every controller just to add login functionality. Even if you ignore the violation of OCP, this just add another risk for you to accidentally forget something.

.. my two cents

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

You may find this wiki page useful.

Answer 8

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.