Architecture more suitable for web apps than MVC?

Question

I've been learning Zend and its MVC application structure for my new job, and found that working with it just bothered me for reasons I couldn't quite put my finger on. Then during the course of my studies I came across articles such as MVC: No Silver Bullet and this podcast on the topic of MVC and web applications. The guy in the podcast made a very good case against MVC as a web application architecture and nailed a lot of what was bugging me on the head.

However, the question remains, if MVC isn't really a good fit for web applications, what is?

Solution 1

It all depends on your coding style. Here's the secret: It is impossible to write classical MVC in PHP.

Any framework which claims you can is lying to you. The reality is that frameworks themselves cannot even implement MVC -- your code can. But that's not as good a marketing pitch, I guess.

To implement a classical MVC it would require for you to have persistent Models to begin with. Additionally, Model should inform View about the changes (observer pattern), which too is impossible in your vanilla PHP page (you can do something close to classical MVC, if you use sockets, but that's impractical for real website).

In web development you actually have 4 other MVC-inspired solutions:

• Model2 MVC: View is requesting data from the Model and then deciding how to render it and which templates to use. Controller is responsible for changing the state of both View and Model.

• MVVM: Controller is swapped out for a ViewModel, which is responsible for the translation between View's expectations and Models's logic. View requests data from controller, which translates the request so that Model can understand it.

  Most often you would use this when you have no control over either views or the model layer.

• MVP (what php frameworks call "MVC"): Presenter requests information from Model, collects it, modifies it, and passes it to the passive View.

  To explore this pattern, I would recommend for you begin with this publication. It will explain it in detail.

• HMVC (or PAC): differs from Model2 with ability of a controller to execute sub-controllers. Each with own triad of M, V and C. You gain modularity and maintainability, but pay with some hit in performance.

Anyway. The bottom line is: you haven't really used MVC.

But if you are sick of all the MVC-like structures, you can look into:

• event driven architectures
• n-Tier architecture

And then there is always the DCI paradigm, but it has some issues when applied to PHP (you cannot cast to a class in PHP .. not without ugly hacks).

Solution 2

From my experience, the benefits you get from an MVC architecture far outweighs its costs and apparent overhead when developing for the web.

For someone starting out with a complex MVC framework, it can be a little daunting to make the extra effort of separating the three layers, and getting a good feel as to what belongs where (some things are obvious, others can be quite border-line and tend to be good topics of discussion). I think this cost pays for itself in the long run, especially if you're expecting your application to grow or to be maintained over a reasonable period of time.

I've had situations where the cost of creating a new API to allow other clients to connect to an existing web application was extremely low, due to good separation of the layers: the business logic wasn't at all connected to the presentation, so it was cake.

In the current MVC framework eco-system I believe your mileage may vary greatly, since the principles are common, but there are alot of differences between, for instance, Zend, Django, RoR and SpringMVC.

If there are truly other good alternatives to this paradigm out there... I'm quite interested in the answers!

Sorry for the slight wall of text!

Comments

[GordonM]

I'm all for compartmentalization, but as pointed out in the podcast, MVC seems like it's not the right approach. The "view" was meant to be an individual display element in a user interface, not the user interface as a whole. Furthermore in Zend in particular, the whole thing seems to be far too dependant on magic - it's hard to know where program flow control will jump next without manually tracing through it with XDebug or the like. That might just be an artefact of Zend's heavy use of singletons and registries though.

[GordonM]

Thanks, these look interesting. Model2, especially. I'll research these and see which one looks like the best fit for what I'm aiming to do.

[hhh]

"To implement a classical MVC it would require for you to have persistent Models to begin with.", what does this sentence infer? Persistent? Repetitive? Without any change? Does it infer "model without side-effects" or something totally different?

[tereško]

In classical MVC the view observes the model (or structures from model layer, to be exact). When state of model changes, the view requests new information. With "persistent model" I meant that model layer exists all thought the usage of application. This is not possible in PHP because when you send the response, the instance from model layer are destroyed. This is a constraint of PHP's Share-Nothing architecture. The is no way for view to observe the model layer .. the is nothing left to observe.

[CoR]

Looks promising n-Tier architecture

[Philipp]

As a sidenote: There are (more or less) complicated solutions to enable persistent sessions in php, which in turn will allow us to create persistent models. This is the solution I am familiar with: us2.php.net/manual/en/intro.memcache.php

[mamdouh alramadan]

(+1, for always explaining in details) @tereško - Sorry for popping up a 2 years old question, but as I was reading I got confused on the difference between a front controller pattern and model2 MVC?

[Katrina]

@mamdouhalramadan Sorry for popping up 3 years later (ha), but my stab at answering your question: The Front Controller is one design pattern, among many, typically used within Model2 MVC. However, Model2 MVC can have 10 controllers, and each controller can render multiple views. This is not using a Front Controller, but still removes controller-view pairing (classic MVC). See here.