When NOT to use MVC in a Web Application?

Question

I was working on sketching out some ideas for a new project, and realized that I was having some difficulty getting things to fit into an MVC framework (In the case, CodeIgniter) In a way I liked. While I believed this can be overcome by working with the design some more and figuring out a better layout, It got me to thinking: could MVC not be the best answer here? and If not, when is using MVC a good idea for a project, and when is it not?

I feel like MVC could be used for any web app, but I'm wondering when is it not the best solution.

Answer 1

I think that MVC is almost universally applicable to web applications that we see today. But it doesn't mean that the framework you use is always up to supporting the types of things that you want to do.

MVC is just a pattern that applies well to the web. In particular it applies well to the idea that an application is accessed in the following way:

• The user asks for some resource
• Some underlying data is retrieved from somewhere.
• A template is then applied to that data in order to show it to the user.

This is undeniably the way the web works, however most Web MVC frameworks start from the assumption that each user produces relatively few requests asking for big chunks of resources at a time. I have found that as web sites move frequent and smaller AJAX style requests lots of frameworks require some work to get them to play nicely because more and more of the 'view' part of MVC needs to be handled on the client. Framework support for this is nowhere near as mature as it is for server side views. However the central paradigm doesnt change much, and the central request - query - template loop is still there.

In short: MVC is a good way to think about the way your application works, but that doesn't mean you are going to find a pre written framework that handles all your needs.

Answer 2

The value of a MVC quickly vanishes when it's...

1. A project with a single developer or small team working in the same coding language
2. A project with a single interface (ex. only a desktop version)
3. A project with a rich UI, code mostly on the client-side, and a battery of AJAX calls
4. Anything that isn't a website (ex. data feed, utility, etc.)
5. Any project where the team members don't care about having "MVC" on their resumes
6. Any project in about 5 years from now when MVC starts to go out of fashion