I’ve come to the conclusion that attempts to do MVC in PHP should instead be called DMVC, the D meaning Data. This is because so many frameworks make the Model the Data and then where do they put the application logic? They usually mix it between the Model and Controller and that ain’t pretty and loses all the advantages of data abstraction. At least if we added a letter to the description people would realize how many frameworks simply get MVC so badly wrong.

A good example would be, if you are using an ORM engine could you switch it to another ORM engine and by changing only the model part of your app get the whole thing working again? Probably not in 90% of cases because you have calls to the ORM layer in your controllers.

You could say then all calls to ORM must go into the model in the form of static functions, for example User::getAllActiveUsers() etc. But then what if you want to page those users or get them in a different order than the default? Soon enough you’d either end up with a hell of alot of static functions or yet another layer in your app that abstracted the ORM technology you are using. Now if the ORM technology in your app was a concern and likely to have to change then this probably would be the direction to take but if not then why spend all the time building it in?

As I think someone else here has said, personally i’m glad that I’m not forced to do things in a particular way and I think that a framework giving you some freedom like that is a good thing, it places the responsibility with the developer to get the application design right. The only reference to the above mentioned examples I have is symfony and as far as I can see it implements ‘model 2′ (the term MVC to me refers more to the classic use of it in stateful apps) perfectly and while giving you the ability to break certain ‘best practice’ principles – like outputting to the view directly from the controller using the reponse object – it also allows you to adhere to those best practices just fine.

Other framework flavors of a similar nature attempt to solve the same problem in different ways. Each of these frameworks applies their own collection of design patterns, and each of those subordinate patterns was designed to solve a low-level problem, many of which could be applied or implemented in different ways (e.g., Mediator, Observer, etc.).

MVC was described in the POSA book as an architectural pattern among the other architectural patterns described in the same book along with a semi-strict explanation of how MVC architectures should be designed to operate as an MVC design pattern (i.e., explicit collections of design patterns are mentioned along with their applied usage).

Since MVC is one way of solving the same problem which is apparently obvious based on the proliferation of frameworks intended to solve the same problem, MVC would probably be better described as one possible implementation for solving the separation of concerns, categorized under a higher level architectural pattern classification that encompasses all other solutions for resolving the same architectural problem.

Corraling all other architectural approaches similar to the original MVC concept which are intended to solve the same architectural problem into the pattern classification of MVC, seems to be more of a mistake made by the academic community.

In the past, we’ve seen similar arguments. For example, there was a discussion a few years back after the announcement of HMVC and how similar it was to PAC. Anyone who has used both PAC and HMVC knows that both architectures were designed to approach the same problem and both used different collections of design patterns to achieve the same goal with different handling of the separation of concerns.

Personally, I feel that architectural patterns need to be classified more strictly based on the subordinate design patterns they apply and how those patterns are applied (which can differ considerably in some cases). Coralling all MVC-like frameworks and their underlying architectural approaches under the MVC pattern name seems like the cause of much of this discussion and a considerable source of confusion.

There is no question Mike is right on just about everything he says – the problem is the forceful uncompromising manner in which he expresses his opinions. It just gets people’s backs up.

The truth is that many of the current frameworks do not enforce the separation between layers that a good Computer Science textbook would advocate to get the right amount of encapsulation, decoupling, etc.

But, alas, they are the best we have and are certainly better than going at it alone from scratch.

Perhaps the code in these frameworks is not something one would submit for a phD thesis, but they do accomplish the goals they have set out to do, which is to get development done faster and smarter.

They are practical professional frameworks which work. They are not academic frameworks which are more “correct”.

Perhaps Agavi will become the be all and end all, eventually. Who knows? There are so many moving parts: the size of the community, the available addons, etc, etc.

Agavi may end up being the purest MVC implementation. If what Mike is describing is true, and if they stay true to their word, it sounds like they are going in a great direction.

But in the meantime, which is probably the next year or two, I am quite satisfied with cakePHP. It may not be perfect theoretical MVC, but it’s a heck of a development framework for getting things done reasonably and quickly.

And you know what, for 95% of the web apps most of us develop and will develop, it is more than enough.

And if you are a PHP developer, as I guess is the case, you would better hope you have been wrong on your next statement, also.

I acknowledge the benefits of both these approaches:
- coding by strict rules in order to get a reliable architecture which can easily adapt to changes, etc;
- making compromises in order to develope an application very fast;
Each one has its strengths and weaknesses and in the end it all comes down to what kind of application you want (and afford) to have. There is, though, in my opinion, a very serious issue with the second approach. Of course, by following it, a developer may not be forced to break healthy architectural rules. Like it has already been said in this discussion, everyone is free to chose for themselves. Unfortunately, though, even if not forced, the developer is encouraged to take the rule-breaking approach, because most (not all, but most) people, when facing a decision will almost always follow the easy way. In this case, this leads to mediocre code writing principles.

Once again, I am not talking about one or another framework in particular, but about the principle of building clean architectures and not breaking pattern rules. I hope I haven’t offended anyone with my opinions and if I have, please accept my apologies. I assure you, it hasn’t been intentional.

regards,
rrainn

Read the code carefully, before you start pointing fingers.. The “forward”-function in symfony is not doing a http-redirect. So your prime example of “ignorance” in symfony is absolutly wrong.

Congratulations!