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

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 2

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