You have your business logic in Recipes:

Recipe.h:

Recipe.m

We put our business logic into a data structure. Implement some methods that manipulate this business logic. This is called our data model.

DataModel.h:

DataModel.m – this is where we manipulate our business logic into a data structure and implement wrapper methods such as add, delete, search, indexOf…etc.

Firing events through Notifications

Model — fire events –> Controller

Our Data Model communicates with other UIViewController by firing Notifications like this in our DataModel.m:

Thus, from our DataModel, we fire a notification called FavoritesChangedNotification or RecipesChangedNotification, which are NSStrings defined in our DataModel.h like this:

Whoever is listening for these notifications will execute their @selector method code.

UIViewControllers listening for Notifications

In our UIViewController we set it up like this:

You can see we have a strong reference to the shared Data Model.

In short: the owner of an object will retain that object and is ultimately responsible for releasing it when it no longer uses that object. When an object is retained, this is called a strong reference. SmoothieViewController has a strong reference to DataModel, because it created that object. SmoothieViewController owns the DataModel for as long as it is alive (which is until this app exits) and will release it in its dealloc.

Whenever we have other UIViewControllers that updates our Data Model like RecipeDetailsViewController, we make it a so-called weak reference like this:

note:
RecipeDetailsViewController does not own the object and therefore does not retain it. Because RecipeDetailsViewController is guaranteed that the DataModel instance will be around for at least as long as it is (i.e. until the user exits the app), it has no need to retain it.

In general, if you pass along pointers to objects you should make them weak references (using the “assign” property semantics), to signify that the object you are giving it to does not assume ownership. You only use “retain” or “copy” when you are not guaranteed that the object may stick around, in which case you become responsible for releasing it when the time comes.
end note.

We then have a UITableViewController displaying the data in our dataModel variable.
What happens if our dataModel changes data? Then in our DataModel.m, these methods will fire Notification like this:

So Data Models post or fire these notifications. We have our UIViewController’s listen for them.

Our UIViewControllers listen up for notifications through [NSNotificationCenter defaultCenter]’s addObserver:

First, make sure the notification strings are set from whichever data models are firing them. In our case its in DataModel.h:

then in your UIViewController’s m file, we set up NSNotificationCenter’s addObservewr:

Once we set up the observer, we implement the method that will execute whenever we receive such a notification in our UIViewController:

What this means is that our UIViewController basically are listening for notifications from our data models. Once there is a notification, we update our view (in our case UITableViewControlelr) accordingly.

Also, remember to remove those observers in your dealloc:

Controller updates Model

Controller — updates –> Model

Now in your ViewControllers we also update our DataModel through using the self.dataModel removeRecipeAtIndex method. Our users manipulate our UITableView, and the interaction calls our commitEditingStyle:forRowAtIndexPath, which then manipulates our weak reference dataModel variable. That is how Controllers update our Models.