MVC design in Cocoa - are all 3 always necessary? Also: naming conventions, where to put Controller

Question

I'm new to MVC although I've read a lot of papers and information on the web. I know it's somewhat ambiguous and there are many different interpretations of MVC patterns.. but the differences seem somewhat minimal

My main question is - are M, V, and C always going to be necessary to be doing this right? I haven't seen anyone address this in anything I've read. Examples (I'm working in Cocoa/Obj-c although that shouldn't much matter)..

1) If I have a simple image on my GUI, or a text entry field that is just for a user's convenience and isn't saved or modified, these both would be V (view) but there's no M (no data and no domain processing going on), and no C to bridge them. So I just have some aspects that are "V" - seems fine

2) I have 2 different and visible windows that each have a button on them labeled as "ACTIVATE FOO" - when a user clicks the button on either, both buttons press in and change to say "DEACTIVATE FOO" and a third window appears with label "FOO". Clicking the button again will change the button on both windows to "ACTIVATE FOO" and will remove the third "FOO" window. In this case, my V consists of the buttons on both windows, and I guess also the third window (maybe all 3 windows). I definitely have a C, my Controller object will know about these buttons and windows and will get their clicks and hold generic states regarding windows and buttons. However, whether I have 1 button or 10 button, my window is called "FOO" or my window is called "BAR", this doesn't matter. There's no domain knowledge or data here - just control of views. So in this example, I really have "V" and "C" but no "M" - is that ok?

3) Final example, which I am running in to the most. I have a text entry field as my View. When I enter text in this, say a number representing gravity, I keep it in a Model that may do things like compute physics of a ball while taking in to account my gravity parameter. Here I have a V and an M, but I don't understand why I would need to add a C - a controller would just accept the signals from the View and pass it along to the Model, and vice versa. Being as the C is just a pure passthrough, it's really "junk" code and isn't making things any more reusable in my opinion. In most situations, when something changes I will need to change the C and M both in nearly identical ways. I realize it's probably an MVC beginner's mistake to think most situations call for only V and M.. leads me in to next subject

4) In Cocoa / Xcode / IB, I guess my Controllers should always be an instantiated object in IB? That is, I lay all of my "V" components in IB, and for each collection of View objects (things that are related) I should have an instantiated Controller? And then perhaps my Models should NOT be found in IB, and instead only found as classes in Xcode that tie in with Controller code found there. Is this accurate? This could explain why you'd have a Controller that is not really adding value - because you are keeping consistent..

5) What about naming these things - for my above example about FOO / BAR maybe something that ends in Controller would be the C, like FancyWindowOpeningController, etc? And for models - should I suffix them with like GravityBallPhysicsModel etc, or should I just name those whatever I like? I haven't seen enough code to know what's out there in the wild and I want to get on the right track early on

Thank you in advance for setting me straight or letting me know I'm on the right track. I feel like I'm starting to get it and most of what I say here makes sense, but validation of my guessing would help me feel confident..

Answer 1

I think all your examples confuse individual operations/functions with the overall app design. So, the general answer to all your questions is that, no, every single operation or function of the app does not have to use all three MVC components.

The real goal of MVC design is to make each component modular and standalone to the greatest extent possible. Therefore, requiring each operation of each component to involve all three MVC components would defeat the purpose of the design pattern in the first place.

Models and Views should be designed such they will in principle work without the other. Models should work whether their data is displayed in windows, in webviews, files, printed or the command line. Views should be able to display the empty version of themselves. Only controllers have to have knowledge of both model objects and view objects but that is because the controllers entire purpose is to link the two.

You questions:

(1) If the UI elements have no need to reference anything outside the immediate view, then the logic controlling the UI elements belong in the view. You know a view is properly encapsulated when you can move it to another project with a different model and a different controller and it still works.

(2) You don't need a model in this case because you're not modeling anything. A model is a data representation of some physical object or action. If the windows and control don't display representative data, then they don't need a model. They're just drawing themselves.

(3) You need a controller so you don't have to rewrite either the model or the view every time you make a change in the other. It is not readily apparent in small projects but once you get one with several different interfaces (UI, network, disk operations etc) and many different ways of representing in each interface, then tying the view to the model breaks in a hurry.

(4) If you don't have a controller, then your model must have references to every single view. The nib system uses the controller as the object that manages the other objects in the nib. You have to have a hierarchal object and the file owner fulfill that role.

(5) The longer and more descriptive the name the better. Six months from now when you come back to do maintenance, you won't remember which window "WindowOpeningController" opens or what, if anything, special it does.

The best way to appreciate MVC is to step back and think about really big, really complex, always evolving apps. Then add in reusing components in different apps. Then add in debugging each component. It rapidly becomes clear why it is great design pattern.