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've recently been wondering the same thing. I'm sure there's an obvious answer other than it's a simple and really small app where MVC would be overkill. Seperation of presentation vs. business logic seems to be a best practice to me.

Answer 2

EDIT: I only noticed the PHP tag after answering the question, however, read the comments as the original question asker found the link useful, so I'll leave this answer here.

Jeffery Palermo (one of the authors of ASP.NET MVC In Action) has a blog post discussing this very thing:

You should NOT use ASP.NET MVC if. . .

He states that you should NOT use ASP.NET MVC if:

• You are not very comfortable with polymorphism
• You aren’t willing to build on top of the framework
• You rely on 3rd party vendor controls for lots of the UI
• You are averse to using open-source libraries

I think the big "show-stopper" in that list could be reliance upon 3rd party controls (particularly GridView replacements etc.) that do not play very well with the MVC framework (i.e. the controls, internally, make use of Viewstate and/or Postbacks). You may well be working in a company that mandates the use of some 3rd party control to handle specific functionality of a web component (GridView or Calendar-style controls being the most obvious that spring to mind) rather than the "built-in" ASP.NET controls that provide similar functionality. Indeed, many of the more complex ASP.NET WebForms based built-in controls do not work so well with the MVC model due to their reliance on viewstate/postbacks and other unsupported functions of the MVC model).

Also, if the ASP.NET application you are building is incredibly small and tightly focused on one function, it could be quicker to develop using the more "traditional" WebForms platform rather than MVC, however, for anything larger (i.e. probably most commercial/corporate applications) MVC is perhaps a better choice as it allows much greater testability of the produced code and promotes a better separation of concerns.

Answer 3

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 4

Basically, MVC serves well when you have an application that needs separation of the data(model), the data crunching(controller), and the presentation of the data(view). This also serves well in an application where the data source and/or data presentation can change at any time. So the data can be coming from a DB, RSS feed, twitter API, etc and can be presented in an RSS feed, normal XHTML, an mobile version, etc. By seperating the app into the three layers, you can develop for all these different scenarios by simply creating a corresponding view or model.

Most of the time, a web site/application seams to somewhat naturally fit into this pattern; partly also because of the popularity of the pattern as of late, some just use it without thinking.

I don't really think this is a direct answer to "when is it not a good idea." I would say when you application doesn't naturally/easily seam to fit the idea. If you have to really shove it into the idea, start changing/adding/deleting things to get it to work as a MVC, then it isn't time for it. Remember that the MVC is a design pattern, so it is a possible solution to a specific circumstance. There are other design patterns for other circumstances that might suit your application better. Here is a link to some good articles introducting design patterns, and then going to some of the basic ones.

Answer 5

When it's a single page application.

( actually it's still worth separating concerns and doing MVC in the small, but it's not MVC in the PHP server sense )

Answer 6

I can't, honestly, think of any scenarios where it wouldn't be advisable to use an MVC approach. It's just a concept--a methodology to keep distinctly different parts of your code separated in a logical and standardized way.

Codeigniter is an excellent framework. I've used it on several occasions. The best thing about it, IMO, is that you don't have to stick to the strict rules that some other frameworks make you stick to. Codeigniter offers you a way to keep your code organized, efficient, and secure but, honestly, you can code however you like within it.

Could you explain a little more about what you mean when you say:

"...and realized that I was having some difficulty getting things to fit into an MVC framework"

I really want to help you make the right decision. Right now, steering away from Codeigniter, to me, seems like a bad decision based on innocent misconception of what it's for.