This chapter is from the book
This chapter is from the book
This chapter is from the book
Using the Model/View/Controller Concepts
One of the critical pieces of iOS and Mac OS is the model/view/controller (MVC) design pattern. Along with object-oriented programming, this is another concept that evolved in the heady days of the 1970s and 1980s when the technology world was addressing the rapidly changing environment in which personal computers were becoming more prevalent and vast numbers of people started using their own computers (and programming them).
Model/view/controller got a frosty reception from some people at the start because it seemed like an over-complicated academic exercise. In retrospect, it seems that perception might have arisen in some cases because the benefits of MVC only become apparent when you apply the pattern and concepts to large systems. Writing "Hello World" using MVC concepts is indeed over-complicated. However, writing Mac OS or iOS in Basic, COBOL, or even C would be something close to futile.
Fortunately, we have complex problems and powerful computers today and MVC has come into its own. The concepts are quite simple:
- Model—This is the data you are working with. With Core Data, you will always have a data model.
- View—This is the presentation of the model and the interface for users to manipulate it.
- Controller—This code is the glue between model and view. It knows details of both, so if either changes, the controller normally needs to be changed, too. However, a change to the view typically does not require a change to the model, and vice versa. The addition of new data to the model will require a change to the view, but that is only because the underlying reality affects both.
One of the mistakes people made early on was to draw a conceptual diagram with a large bubble for the model and another large bubble for the view. The controller was relegated to a small link. In practice, that is far from the case. The controller is often the largest set of code modules. For people used to traditional programming, working on a controller feels most like traditional programming. Both the model and the view can be highly structured, but it is in the controller that all the idiosyncrasies emerge and collide.