What are the downfalls of MVC? [closed]

Question

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.

Answer 1

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.

Answer 2

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:

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.