Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as too broad by gnat, GlenH7, Mathew Foscarini, rjzii, Eric King Aug 9 '13 at 19:19

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.If this question can be reworded to fit the rules in the help center, please edit the question.

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 Aug 8 '13 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. –  Ben McDougall Aug 8 '13 at 13:01
1  
How much variety is there in your different jobs? –  JeffO Aug 8 '13 at 13:46
    
Have a read of 'MVC is not object oriented'. –  mcintyre321 Aug 8 '13 at 15:13
    
@JeffO PHP apps (backend, non-JS heavy sites), front-end apps. So, all web, but front-end and backend. –  Oscar Godson Aug 9 '13 at 19:10
show 2 more comments

5 Answers

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.

share|improve this answer
8  
actually you can implement MVC anytime you have an abstraction layer; the API is the view/controller and the underlying logic is the model –  ratchet freak Aug 8 '13 at 12:51
9  
@ratchetfreak, technically speaking an API is a form of UI, where the user is the programmer using the API. –  zzzzBov Aug 8 '13 at 13:00
    
@ratchetfreak: wouldn't this be classified as the façade pattern? –  Jeroen Vannevel Aug 8 '13 at 13:23
1  
MVC may be most useful in UI, but it's separation of concerns is hardly only useful there. –  DougM Aug 8 '13 at 13:31
1  
@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 Aug 8 '13 at 20:01
show 4 more comments

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. Command line programs don't have an interface per se. 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.

share|improve this answer
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 Aug 8 '13 at 13:34
add comment

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.

share|improve this answer
    
+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 Aug 9 '13 at 17:14
add comment

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.

share|improve this answer
    
+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 Aug 9 '13 at 8:35
    
@Robbie : ahh!! feature creep! –  DougM Aug 9 '13 at 14:51
add comment

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.

share|improve this answer
add comment

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