QotD: MVC
Posted January 27th, 2005 @ 11:29am by Erik J. Barzeski
Question: What is the biggest limitation of the Model-View-Controller paradigm?
My Answer: I just wanted to use the word "paradigm." 🙂 No, not really. The largest issue I have with it is that it's somewhat complicated by some classes in Cocoa, and sometimes it just feels so easy to do something "M" in the "V" or to do something "C" in the "M." So you cheat once. Then again. Then again. Eventually, well, your app is more "MVMMCCMMCMMCMMCMCMCMMMCVVMVMVC" than "MVC." 😛
You are encouraged to answer the Question of the Day for yourself in the comments or on your blog.
Donate Life
Posted 27 Jan 2005 at 12:22pm #
For me, the worst thing about MVC is actually separating all the objects properly. Sometimes, I just want to get a variable from the M in the V... I have to write an accessor in the M, then a method in the controller to get it for me.
It's just easier to get the V to ask the M for the data, rather than going through the controller.
Posted 27 Jan 2005 at 12:48pm #
I guess this isn't a limitation with the "paradigm" but the problem for me is this: I'd like to use Cocoa Bindings. They're sweet, and I've poked around enough with them to make me *want* to use them.
But, since my work is robotics simulation, AI and on the side game development, all my models are written in C++, for reasons of portability and performance. Thus, bindings at least won't work.
This is the strength however of the pure MVC relationship. My models, being C++, use stuff like std::vector, std::string, std::map, etc etc. An Objective-C++ controller can effectively hide that from a pure Cocoa view. Which is pretty sweet.
Posted 27 Jan 2005 at 3:32pm #
In general I agree with Erik. I have found myself adding stuff to the view that should "in practice" be in the model, but its so much easier to keep it there. For me I think of various bits of logic that should be in my PHP Object code but to make the interface work it ends up in JavaScript, which is tied to the page itself.
Posted 28 Jan 2005 at 12:12am #
The "problem" with MVC, is that people look at it too linearly. It's not that you must have them be seperate classes that are all seperate and distinct, but rather you can have them all in the same class as long as that seperation is intact. For example I often see people that are confused into thinking that MVC means one model, one view, and one controller layer. MVC works best when there are several layers to the interactions. That "model" at one layer might be the controller of a lower layer that is doing some sort of operations over the data handed up from lower levels.
Often people cheat not because they have, but because it's simply easier to have something locally. You can do that, it's fine, if you got it through a controller, since that way you can change the model hand the view a different object and it's still MVC and everything still works. Basically you get to maintain reusability and flexibility while having useful local state.