Cocoa Design Patterns by Erik Buck and Donald Yacktman is a good resource for understanding how various design patterns are used in Cocoa. Although the book is a couple years old and written for Cocoa rather than Cocoa Touch, the two frameworks are conceptually very similar, and the additions in iOS 5 and 6 do little to change the underlying ideas, especially the ones you’re asking about.

How to separate a model from the view controller. I think I know how
to do this by simply replacing the NSArray style example with a
specific model object, however what I do not know how to do is alert
the view when the model changes.

The model generally won’t talk to the view directly — it should go through the controller. You have a number of options in this respect, including but not limited to:

• Have the view controller observe relevant parts of the model using Key Value Observing.

• Use notifications.

• If the model is changing due to user input, the view controller may know to expect some aspects of the model to change.

• Use delegation. Define a delegate protocol for your model and adopt it in your view controller. Set the view controller as the model’s delegate.

How to create a service model for my domain objects…

From your comment I see that you’re looking for a way to manage your graph of model objects. The Core Data framework provides object graph management and persistence — it makes it easy to work with your data as objects without having to worry about how to store it all in database tables. It’s fast and performs well even with relatively large amounts of data.

Great question. I’ve struggled with finding the best way to build objective-c apps which adhering to MVC and I find that the using delegates is often the cleanest approach to synchronize views with models.

So, if your model is loading something over the network, the delegate might look like this:

@protocol XXItemLoadDelegate <NSObject>
- (void) willLoadItemWithIdentifier:(NSString*)identifier;
- (void) didLoadItem:(XXItem*)item;
- (void) didFailToLoadWithError:(NSError*)error;
@end

And I think it’s clear how a view might show/hide a busy indicator and then update once the item loaded.

The main disadvantages to the delegate pattern are:

• forgetting to set the delegate
• forgetting to call the delegate events in the model
• overwriting the delegate (when multiple views want to be notified)
• reseting the delegate (e.g. if a view is reused, the delegate should be nil first)
• painful to refactor if you decide you need multiple observers
• giving the the protocol and delegate methods consistent names

Despite all these drawbacks, I prefer the explicitness of delegates to other approaches.

NSNotifications are great for keeping completely unrelated pieces of code synchronized. But I’ve found they should be used sparingly, as it makes code incredibly hard to trace and debug.

KVO is also an option for syncing views to models, but I don’t have much experience with using it in larger projects.

I didn’t much care for the Cocoa Design Patterns book. It seemed out-of-date, and didn’t have as much practical information as I would have hoped.

Instead of books, I’d also recommend reading through larger iOS projects on github. You can always see some design patters in action – and learn a few good tricks. For example:

App Sales Mobile