In this exercise, you expanded on the BNRItemStore to allow it to save and load BNRItem instances from the filesystem. The controller object asks the BNRItemStore for the model objects it needs, but it does not 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 BNRItemStore 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 exposes a number of methods that allow a controller object to fetch and save model objects. The details of where these model objects come from or how they get there is left to the store. In this chapter, 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.

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.

Many developers talk about the Model-View-Controller design pattern. In this chapter, we have extended the idea to a Model-View-Controller-Store design pattern.