In this exercise, we expanded on the PossessionStore to allow it to save and load Possession instances from the filesystem. The controller object asks the PossessionStore for the model objects it needs, but it doesn’t have to worry about where those objects actually came from. As far as the controller is concerned, if it wants an object, it will get one; the PossessionStore is responsible for making sure that happens.

The standard Model-View-Controller design pattern calls for the controller to be bear the burden of saving and loading model objects. However, in practice, this can become overwhelming – the controller is simply “too busy” handling the interactions between model and view objects to deal with the details of how objects are fetched and saved. Therefore, it is useful to move the logic that deals with where model objects come from and where they are saved to into another type of object: a store.

A store simply exposes a number of methods that allow a controller object to fetch and save model objects. Where these model objects come from is up to the store: in this exercise, the store worked with a simple file. However, the store could also access a database, talk to a web service, or use some other method to produce the model objects for the controller. The controller doesn’t care – it will get the model objects it wants, and the details are abstracted into the store.

One benefit of this approach, besides simplified controller classes, is that you can swap out how the store works without modifying the controller or the rest of your application. This can be a simple change, like the directory structure of the data, or a much larger change, like the format of the data. Thus, if an application has more than one controller object that needs to save and load data, you only have to change the store object.

You can also apply the idea of a store to objects like CLLocationManager. The location manager is a store that returns model objects of type CLLocation. The basic idea still stands: a model object is returned to the controller; the controller doesn’t care where it came from.

Thus, we introduce a new design pattern called Model-View-Controller-Store, or simply MVCS. It’s the hip, new design pattern that programmers are talking about everywhere.