I've been using MVC/MV* since I started actually organizing my code years ago. I've been using it so long that I can't even think of any other way to structure my code and every job I've had after being an intern was MVC based.

My question is, what are the downfalls of MVC? In what cases would MVC be a bad choice for a project and what would be the (more) correct choice? When I look up MVC alternatives, nearly every result is just different types of MVC.

To narrow down the scope so this doesn't get closed, let say for web applications. I do work on the backend and front-end for different projects, so I can't say just front-end or backend.

  • 5
    There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
    – gnat
    Commented Aug 8, 2013 at 10:10
  • 8
    I would need an answer of what your definition of MVC is before I could reply to your question as the MVC architecture only applies to a set of problems as is. So if you use it in the wrong place you have a downfall. Commented Aug 8, 2013 at 13:01
  • 1
    How much variety is there in your different jobs?
    – JeffO
    Commented Aug 8, 2013 at 13:46
  • Have a read of 'MVC is not object oriented'. Commented Aug 8, 2013 at 15:13
  • @JeffO PHP apps (backend, non-JS heavy sites), front-end apps. So, all web, but front-end and backend. Commented Aug 9, 2013 at 19:10

5 Answers 5


You should always remember - MVC is a UI-related pattern. If you are building a complex application you should take everything, that is not related to UI, out of MVC triplets to any other classes, subsystems or layers.

It was my biggest mistake. I spent a long time understanding that simple rule:

  • Do not spread a MVC pattern amongst the whole application,
  • Limit it to UI-related stuff only.

Always check if the code you write is logically in the correct place, meaning it logically fits into it's area of responsibility of the class you place it in. If not - move the code away as soon as you understand it.

All the patterns that you call MVC-alternatives (i.e. Model-View-Presenter, Model-View-ViewModel) are just a way of implementing the general MVC concept.

  • 10
    actually you can implement MVC anytime you have an abstraction layer; the API is the view/controller and the underlying logic is the model Commented Aug 8, 2013 at 12:51
  • 14
    @ratchetfreak, technically speaking an API is a form of UI, where the user is the programmer using the API.
    – zzzzBov
    Commented Aug 8, 2013 at 13:00
  • @ratchetfreak: wouldn't this be classified as the façade pattern? Commented Aug 8, 2013 at 13:23
  • 2
    MVC may be most useful in UI, but it's separation of concerns is hardly only useful there.
    – DougM
    Commented Aug 8, 2013 at 13:31
  • 2
    @DougM true. more specifically: the specific style of separation in MVC was created for GUI applications. later on, the concept was expanded to web applications, losing a big deal of specificity. extending it further to API designs make it even more vague. beyond that... I think it loses most of its value and it would be better to start fresh with the more basic (and universal) concept of separation of concerns.
    – Javier
    Commented Aug 8, 2013 at 20:01

In my opinion there are two types of MVC - pure and impure (for the lack of a better word :)

Pure MVC is what was introduced into small talk:

enter image description here

This was intended for personal computing/desktop applications. As you can see, the model informs the views of any updates/changes made to it. Not so with (impure) MVC.

The other (impure) MVC that's touted for web applications is more of a PAC (Presentation-abstraction-control) pattern instead of the classic MVC above. That's more of code organization and separation of concerns:

  • Model: Abstraction for stored data
  • Control: Usually what is known as the business logic layer as well as part of the application responsible for routing the HTTP requests to the corresponding business logic (aka controller)
  • View: Mostly view templates that format the data from the model and return it to the client. The model NEVER sends updates to the view neither does the view 'subscribe' for updates from a model. It'd be coupling nightmare. Hence it's more like PAC than true MVC.

Now, here's how a web application is usually structured:

  1. Front-end: MVC on client using frameworks as Backbone.js etc., This is the 'true' MVC form in essence.
  2. Back-end: Again, you do have (impure) MVC/PAC for code organization and separation of concerns
  3. Global web app (for the web application as a whole): If you have RESTful backend that returns only JSON data, then your entire backend can be perceived as a model for the front-end client application where the View and Controller reside in essence.

So what are some disadvantages of MVC? Well, the pattern has stood the test of time so there aren't many that matter all that much other than it being a bit 'complicated'. You see, the MVC is a compound pattern - implements strategy/observer pattern and all are well arranged to form a high level pattern.

Should you use it everywhere? Maybe not. Extremely complex web applications maybe split into multiple layers! You may not be able to get away with just View/Business Logic/Data layers. The overarching framework/organization may still be MVC-ish, but only at a macroscopic level.

Here's an example where just MVC by itself maybe a bad choice: Try designing air traffic control system or a loan/mortgage processing application for a large bank - just MVC by itself would be a bad choice. You will inevitably have Event buses/message queues along with a multi-layered architecture with MVC within individual layers and possibly an overarching MVC/PAC design to keep the code base better organized.

  • +1 for "pure vs. impure". although i prefer to use "GUI vs Web MVCs", and point that GUI MVC is modular while Web MVC is layered. I really wish the Web MVC was called something else, since it's too different from "pure MVC", but it seems it's too late for that.
    – Javier
    Commented Aug 9, 2013 at 17:14
  • I like the diagram. Re. the wording, maybe "traditional MVC vs derived MVC" :)
    – Edwin Yip
    Commented Jan 4, 2015 at 14:01

The mistake a lot of people make with design patterns is seeing it works beautifully in one place and then trying to apply it everywhere.

If you've worked in one place for a while, you can almost date a piece of code by seeing what technologies/design patterns/practices were in vogue at the time e.g. singletons/dependency injection/TDD etc etc.

As for where not to use it. Well, wherever one element of the MVC triplet doesn't apply. Console applications may not implement an interface at all. Utility programs may not have a model. And arguably, if you have neither a model nor a view, you don't require a controller.

The problem is rarely with the concept - more with the implementation. No matter how good the paradigm is, take the time to see if it is a good fit for the problem in hand.

  • 2
    MVC, if properly followed, allows for code re-use. the same logic behind a utility or command-line project can easily be an identical controller from a larger program with an alternative model and view. (such may not be the most EFFICIENT code, but that's not always a concern.)
    – DougM
    Commented Aug 8, 2013 at 13:34
  • Console is a UI. Just text based, so your assumption is wrong.
    – GuardianX
    Commented Oct 1, 2016 at 18:33
  • @GuardianX I didn't really word that bit very well at all. I've edited my answer to clarify.
    – Robbie Dee
    Commented Oct 3, 2016 at 11:55

MVC, like any paradigm not integral to your development platform, is increased complexity. It's drawback is that you may wind up seperating classes that should not be separate, and decreasing clarity of how tightly bound they are. (Or, for trivial projects,even obfuscating your code.)

The alternative for the first problem is to separate out such code into independent sub-projects; the alternative for the second is un-seperated code, either at the class or file model.

  • +1 for mentioning smaller projects although I appreciate that there are various schools of thought here. Some would say that if there is a chance a POC could evolve into live code, it should be written properly. Whilst others say that rather than risk wasting time polishing something that could never be used, it would be better to rough something together and then start over if the project went forward.
    – Robbie Dee
    Commented Aug 9, 2013 at 8:35
  • @Robbie : ahh!! feature creep!
    – DougM
    Commented Aug 9, 2013 at 14:51

My understanding of applying MVC/MV* is following the principle of Separation of Concerns (SoC) - separating program/codes into distinct sections/pieces so that each section could address a separate concern (Ref: http://en.wikipedia.org/wiki/Separation_of_concerns)

there are a lot of benefits when separating concerns: one won't affect another and developers could work on a unit without impacting the rest, etc. & etc... MVC is not the only pattern that follows SoC, basically, OOP itself is a great concept to break things into units.

MVC/MV* are very useful when you handling UI related development, while underneath there could be more patterns - factory, singleton, facade and etc. Majority of big projects consist of multiple layers handling different aspects, but UI might not be a must for some cases. You may see MVC a lot - that's because a lot of projects have UI elements.

thus, While talking about the drawbacks of MVC, it really depends the projects you are doing - does it have UI? does it require great scalability/extensibility? does it have many interactions between UI and behind-system? for example, a simple information web page does not require MVC at all, unless you plan to extend it to a great interactive page in the future.

so in order to evaluate MVC (or more general - a design pattern), give it a context and think about complexity, scalability, testablity, maintenance, time constraint, etc. & etc.

Not the answer you're looking for? Browse other questions tagged or ask your own question.