tags:

views:

625

answers:

9

I've been reading through a couple of questions on here and various articles on MVC and can see how it can even be applied to GUI event intensive applications like a paint app.

Can anyone cite a situation where MVC might be a bad thing and its use ill-advised?

EDIT: I'm specifically talking about GUI applications here!

+14  A: 

I tried MVC in my network kernel driver. The patch was rejected.

Aiden Bell
+1 good one! :-)
marc_s
Ha I'm contemplating updating my question to specify GUI apps..!
joshcomley
:P thanks marc_s
Aiden Bell
@joshcomley - Might be a good idea hehe
Aiden Bell
@Josh -- I agree. As it is, the question is a bit like asking "what are some jobs where using a screwdriver would be a bad thing" -- limiting the question to instances where using a screwdriver would even be meaningful will result in better answers. Aiden's is funny, but not particularly useful except to point out the obvious limitations of the tool.
tvanfosson
+1  A: 

MVC makes sense for web applications. In web applications, you process some data (on SA: writing questions, adding comments, changing user info), you have state (logged in user), you don't have many different pages, but a lot of different content to fit into those pages. One Question page vs. a million questions.

For making CMS, for example, MVC is useless. You don't have any models, no controllers, just a pages of text with decorations and menus. The problem is no longer processing data - the problem now is serving that text content properly.

Tho, CMS Admin would build on top of MVC just fine, it's just user part that wouldn't.

For web services, you'd better use REST which, I believe, is a distinct paradigm.

WebDAV application wouldn't benefit greatly from MVC, either.

The caveat on Ruby for Web programming is that Rails is better suited for building Web applications. I’ve seen many projects attempt to create a WebDAV server or a content management system CMS with Rails and fail miserably. While you can do a CMS in Rails, there are much more efficient technologies for the task, such as Drupal and Django. In fact, I’d say if you’re looking at a Java Portal development effort, you should evaluate Drupal and Django for the task instead.

alamar
Why would you not have models in a CMS? Surely each "function" of the CMS could have a controller to go with it?
joshcomley
Corrected: you can make your admin pages use MVC, but user pages are just pages of text, there are no distinct "functions" there, instead there are a handful of menus, a header, some text, a template to fit them all.
alamar
@alamar -- sounds like a model to me.
tvanfosson
You have no model 'cause CMS pages are stateless and don't process any data. Unless I've misunderstood you.
alamar
Each page has an id that identifies it. It has associated menus, a header value, some text. Your controller has an action to render a page by id, it pulls the header, the associated menu, the text, and the proper template (view). It renders the chosen view with the given data. I'm not saying that it's a good fit (partly because I haven't thought about it), but you do have a model.
tvanfosson
This way, you've got a dozen controllers per page (a few MenuControllers, HeaderController, ContentController, RotationController), MVC frameworks wouldn't like that.
alamar
script/generate scaffold Page title:string body:text category_id:integer page_template_id:integer -- Would need some creative routes, but there you go. IMO MVC is a better fit for CMS then something like php or asp, since all pages are based on data from the database, not actual files.
Matt Briggs
It wouldn't work except for simpliest CMS.You'd have one Model (with one field) in your web-app, one Controller, and a mess of code in that one controller.And yeah, you haven't got category_id, you've got parent: you've got a tree of pages! And body isn't text, it's a collection of blocks.
alamar
with proper model, MVC can nail CMS development beautifuly
Arnis L.
Any actual arguments? Teh links?
alamar
why would django be better suited than rails, are they not much the same? or did i misread your point?
Adam Taylor
No, they're pretty different. Django comes with admin system, but it's more low level. Rails provide a lot of convenience functions on top of that low-level, but you wouldn't need them for CMS anyway.
alamar
+1  A: 

Anything where you want to drop in 3rd party components will make it tough to work in the MVC pattern. A good example of this is a CMS.

Each component you get will have their "own" controller objects and you won't be able to share "control" of model -> ui passing.

Alex
Depends on whether the 3rd party components are built to work in an MVC world. They could be built to work with specific models and not require separate controllers, with your own controller/action providing the model required. I already have a few instances of user controls that could eventually be refactored into generic components.
tvanfosson
See Typo3 Tree of Plugins or Vanilla's Garden Framework how they solve this issue in PHP.In Ruby/Rails you use mixins/modules to inherit "common" Controller code.If you want to e.g. reuse user authentication then you can either use a filter in the Controller itself or declare your code in Application/Base controller of your framework.To summarise: Working with 3rd party components is only and in all scenarios hard if they don't have though-out interfaces.
Radek
A: 

When is it a bad thing? Where ever there is another code-structure that would better fit your project.

There's countless projects where MVC wouldn't "fit", but I don't see how a list of them would be of any benefit..

If MVC fits, use it, if not, use something else..

dbr
I'm not after a list of applications, I'm after some generic justifications for not using MVC
joshcomley
+6  A: 

I think you're looking at it kind of backwards. The point is not to see where you can apply a pattern like MVC, the point is to learn the patterns and recognize when the problem you are trying to solve can naturally be solved by applying the pattern. So if your problem space can be naturally divided into model, view and controller then it is a good candidate for MVC. If you can't easily see which parts of your design fall into the three categories, it may not be the appropriate pattern.

Robert
Good point. The question arose from everytime I couldn't find a way to fit it, a Google search and a few reads later finds a way to use MVC - in a natural and useful manner.
joshcomley
+1 for a different perspective - always a useful approach!
Treb
+1 I agree MVC is a description of a problem class rather than a solution outside of that class.
Aiden Bell
+1  A: 

I don't necessarily know that MVC is ever really a bad idea for a GUI app. But there are alternatives that are arguably better (and also arguably worse depending on whose opinion you're asking). The most common is MVP. See here for an explanation: Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask.

Although I suppose it might be a bad idea to use MVC if you're using a framework or otherwise interacting with software that wasn't designed with MVC in mind.

In other words, it's a lot like comparing programming languages. There's usually not many tasks that one can say that one is better than the other for. It usually boils down to programmer preference, availability of libraries, and the team's experience.

Jason Baker
+1  A: 

MVC shouldn't be used in applications where performance is critical. I don't know if this still applys with the increase of computing power but one example is a call center application. If you can save .5 seconds per call entering and updating information those savings add up over time. To get the last bit of performance out of your app you should use a desktop app instead of a web app and have it talk directly to the database.

Jared
Stackoverflow is built using MVC and jeff has said that performance is critical. SO is really fast as well so i don't think performance is an issue.
Alex
Yes from my experience MVC lends itself to good practise and I've never seen a performance overhead from using the MVC paradigm itself.
joshcomley
A: 

MVC and ORM are a joke....they are only appropriate when your app is not a database app, or when you want to keep the app database agnostic. If you're using an RDBMS that supports stored procedures, then that's the only way to go. Stored procs are the preferred approach for experienced application developers. MVC and ORM are only promoted by companies trying to sell products or services related to those technologies (e.g. Microsoft trying to sell VS). Stop wasting your time learning Java and C#, focus instead on what really matters, Javascript and SQL.

Experienced Developer