MVC with cocoa/objective-c

Question

Hi all,

I have a strong j2ee background, and I am trying to move to objective-c for some desktop/iphone programming.

I used many java web frameworks with mvc in mind, spring and struts ecc... so I am used to have servlet or controller which pass attributes to jsp pages, which is the view. In jsp pages with jstl you can call this attribute and render to video. In this way controller and view are (in theory) clearly separated.

With xcode, I can easily recognize the controller and the view built with IBuilder. All the tutorial I found, shown the controller which go and change directly labels or text fields.

So my two questions:

1. seems to me that there's no separation between the two (controller and view), where I am wrong in that ?
2. is there a way for a controller to pack all objects in a kind of context in a j2ee way and have the view read that context ?

thanks Leonardo

Answer 1

I do not understand your second question (I've never used J2EE), but I think I can make some headway answering your first.

Cocoa does not enforce MVC; it just strongly encourages it -- especially for larger projects. Consider an example program, one that has an NSTableView bound to an NSArrayController.

In this case, the NSTableView is clearly the view (it has the word "view" in its name) and the NSArrayController is clearly the controller (it has the word "controller" in its name).

The model is an NSArray that the NSArrayController knows about, but you probably don't interact with that model directly. You will instead ask the NSArrayController to manipulate its model by sending addObject: and removeObject: messages to the array controller (and not to the array itself).

When you do this, the NSArrayController will effect a change in the NSTableView via bindings. Again, you don't ever ask the NSTableView to do anything.

So you never talk to the view and you never talk to the model. Everything you want to happen goes through the controller.

MVC. QED.

Of course, maybe the way your project works, the view should be its own controller. The world won't end, although you might find it to be a little more difficult to go against the grain of the framework. But you should always try to use the best approach for the job at hand instead of insisting on some sort of design pattern purity.

Answer 2

In most of the examples you have read you probably saw something like this:

[myTextfield setStringValue:myString];

now in this case sure the controller is updating the textfield directly, however as myTextfield is usually an IBOutlet it can be any textfield in your view, or even nil. quite possibiy it doesn't even need to know that it is an NSTextfield just that it responds to a setStringValue method. In this sense there is a seperation between the controller and view.

Now in your comments above you were concerned with seperation of responsibilities within MVC but did not mention the model much. With Cocoa bindings you can bind directly to model keypaths, in this case the model neeed not know anything at all about the view.

MVC is a bit of an ambiguous concept with no hard definition. It can mean different things to different people. For me it means that the view has knowledge of the controller ( through outlets or bindings) limited knowledge of the model(through bindings). The contoller has full knowledge of the model and limited knowledge of the view(through outlets). Finally the model has zero knowlege of the view and ideally no knowledge of the controller.

With regard to your second question, I don't use j2ee, but I think you can acheivee what you want by having your controller update a context ivar ( probably a NSDictionary) then in your view bind to this context with a keypath. However there is no real need to wrap everything up bindings are very versitile and u can bind to any property.