45

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.

Oscar Godson
  • 829
  • 1
  • 7
  • 12
  • 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 08 '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 08 '13 at 13:01
  • 1
    How much variety is there in your different jobs? – JeffO Aug 08 '13 at 13:46
  • Have a read of ['MVC is not object oriented'](http://c2.com/cgi/wiki?MvcIsNotObjectOriented). – mcintyre321 Aug 08 '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 09 '13 at 19:10
  • @gnat Added more details. Hopefully that's good enough. Not sure how much more I can narrow it down tho. – Oscar Godson Aug 09 '13 at 19:13
  • @BenMcDougall I've made my question a little more precise (see the last paragraph in the OP), but I don't really have my own definition of MVC. Just the widely accepted one I guess. So: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller – Oscar Godson Aug 09 '13 at 19:16

5 Answers5

49

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.

Hedin
  • 851
  • 6
  • 11
  • 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 – ratchet freak Aug 08 '13 at 12:51
  • 14
    @ratchetfreak, technically speaking an API *is* a form of UI, where the user is the programmer using the API. – zzzzBov Aug 08 '13 at 13:00
  • @ratchetfreak: wouldn't this be classified as the façade pattern? – Jeroen Vannevel Aug 08 '13 at 13:23
  • @JeroenVannevel If you consider facebook as JSON API, or twitter as JSON API, you will realise that facade will be too "fat" for this cases. – Hedin Aug 08 '13 at 13:28
  • 2
    MVC may be most useful in UI, but it's separation of concerns is hardly only useful there. – DougM Aug 08 '13 at 13:31
  • @DougM: separation of concerns (or rather, single responsibility) is a big part of OOD and other design styles; but the specific choices made by MVC aren't so universally applicable. – Javier Aug 08 '13 at 13:42
  • @Javier: I didn't say they were. but there is a world of difference between "universally applicable" and "only useful in UI." – DougM Aug 08 '13 at 16:33
  • 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 Aug 08 '13 at 20:01
  • @Javier has hit on something I was becoming more and more concerned about as I read the thread. Just because you're an advocate of SOC, it does not mean that MVC should be an automatic paradigm choice. Also, just because various MVC frameworks allows either the M, V or C to be omitted, this does not mean you can just write anything within the framework and call it an MVC application. – Robbie Dee Aug 09 '13 at 08:20
  • Saying that MVC is only useful in UI-based applications is wrong. If your application have to show something to human (UI, game, console, w/e) it must be designed with MVC in mind. – GuardianX Oct 01 '16 at 18:31
  • @GuardianX If it is human-interaction - it is UI, though it don't think that application *must* follow MVC. MVC is just an instrument, moreover one of available. – Hedin Oct 03 '16 at 08:53
  • @Hedin yes, but unfortunately people nowadays always try to reinvent the wheel which ends up being MVC in a nutshell. But unreadable and unmaintainable one. – GuardianX Oct 03 '16 at 12:09
17

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.

PhD
  • 2,531
  • 2
  • 18
  • 32
  • +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 09 '13 at 17:14
  • I like the diagram. Re. the wording, maybe "traditional MVC vs derived MVC" :) – Edwin Yip Jan 04 '15 at 14:01
13

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.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • 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 08 '13 at 13:34
  • Console is a UI. Just text based, so your assumption is wrong. – GuardianX Oct 01 '16 at 18:33
  • @GuardianX I didn't really word that bit very well at all. I've edited my answer to clarify. – Robbie Dee Oct 03 '16 at 11:55
3

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.

DougM
  • 6,361
  • 1
  • 17
  • 34
  • +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 09 '13 at 08:35
  • @Robbie : ahh!! feature creep! – DougM Aug 09 '13 at 14:51
0

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.

Rex
  • 126
  • 4