[Amorya]

I seem to be in over my head here. I kinda understand the individual concepts of Cocoa design, but starting with a new blank app is causing me loads of problems of the type "What do I do next?"

My app is a client for a multi user bell-ringing server. So far I've created a nib file for the tower view, and started creating my header files... but I am a bit stuck.

Classes I am planning are:

Tower - contains details (model) about a tower.
TowerController - the controller for the tower - handles things like a new ringer joining.
TowerManager - only one instance for the whole app - manages creating new TowerControllers.
Bell - the model for a bell. Contains its image file and sound, and also who is currently holding it.
Ringer - model for each user currently on the system
TowerView - a custom view that draws a set of bells in a circular formation
TowerViewController - I'm not sure about this one. A friend suggested I separate the model-controller from the view-controller... it seems complex to me.
Networking - not really decided on the classes for this yet, but it'll wait for data, split it into packets, and send messages to the appropriate controller.

I'm trying to plot how the messages should go - but it's hard. Take the example of when a new tower is opened. The server tells you to add bells to the tower one at a time. So networking sends AddBellWithName:Image: to TowerController, which creates a new Bell object and adds it to the MutableArray in Tower - or should AddBellWithName:Image: be sent to Tower (the model)? Also, to get the bell displayed, TowerView must be told something - should it be passed a Bell object, or just a string/image combo?

Thanks for any help you can give me!

A very confused
Amorya


PS: if any of you have read the spec and would implement this app in a different way, then it'd be great if you could mention how you'd do it!

[smeger]

A big part of the idea is that the different layers shouldn't know any implementation details from the other layers.

So networking sends AddBellWithName:Image: to TowerController, which creates a new Bell object and adds it to the MutableArray in Tower.

If it added it to the NSMutableArray in Tower, it would be using implementation knowledge. It should send Tower an addBell message with the new Bell object.

Likewise, the view should know nothing about how the model works or what it means - the view's only job is to display content and interact with the user.

Also, to get the bell displayed, TowerView must be told something - should it be passed a Bell object, or just a string/image combo?

If you gave the view a Bell object, the view wouldn't be reusable later on when the Bell object changes to something else. The view shouldn't have knowledge of the model, it should only display content and send change requests on to the controller. String/image combo.

Of course, I don't really use MVC religiously, so add a large grain of salt.

[Detrius]

A simple way to describe it is that the controller is what makes the view capable of talking to the data. The data should know nothing of the view, and the view shouldn't need to know anything about how the data is arranged.

[Amorya]

Thanks for the help guys! I've been working on the view up to now - have created WBLCircularView. It's a class that displays an arbitary number of NSViews in a circle, resized appropriately. It also has actions to allow rotation of the whole circle.

It's slow progress, but I seem to have managed this class OK

Amorya