Well, let me start by saying that software engineers can waste hours and hours arguing about these details. I'm not going to claim that my implementation is a perfect example of MVC. Obviously people can always argue about which implementation details should go where. And different software engineers will often have contradictory, but equally valid opinions on the matter. In fact, this issue has come up before.

However, I would like to make a couple of points.

1) The views shouldn't know about the model--but they do need access to the data. Obviously we cannot make a graph without somehow passing the relevant data onto the graph view. In my mind, the WeightEntry object is part of the data, while the WeightHistory is the model itself. You definitely wouldn't want to pass the WeightHistory on to the view--but passing an array of WeightEntries is (in my mind) OK.

Yes, we could probably pass the data around in a more-raw form--but that would just make the application more complex and harder to maintain, without giving us any benefits.

It might make more sense to move the GraphStats from the Views group to either the Controllers or Model group. After all, the GraphStats isn't really a view (it doesn't display anything--it's all about crunching numbers). However, since it's only used by the GraphView, I found it convenient to store it there.

2) Remember the reason why we're dividing the component into three modules. We want to clearly separate our functions and have those roles loosely bound together. This makes the application easier to modify and maintain.

The model is responsible for managing the state of our data. The view is responsible for displaying the data. The controller is largely the glue that holds the two together. How loosely should the bounds be? Well, a good rule of thumb is that you should be able to replace the model without affecting the view (or vice versa). Again, our goal is to create an application that can be easily maintained and modified in the future--not to slavishly adhere to an artificial set of rules.

Note that my implementation passes the pragmatic test of MVC design. In Chapter 7, we gut out the old model and replace it with a new model. This requires a few small changes to the view controllers--but the views themselves are unchanged. They don't know anything about the modifications.

3) When working on any large piece of software, you will undoubtedly find problems with your design. Maybe its having model and view objects too tightly coupled (or any objects too tightly coupled for that matter). It may be having too much repetition in your code. You can almost always find places where the code could be cleaned up. This is the reason why we should refactor our projects periodically--cleaning up these places wherever we can. Unfortunately, most development teams are too focused on just finishing a project, and don't spend nearly enough time refactoring.

4) Real world projects tend to get messy fast. Good design is an ideal we should strive for--we need it to keep this messiness under control. But, ideal solutions are not always possible.

I'd argue that Apple doesn't use a pure MVC implementation in the iOS SDK. The view controllers and the views are actually rather tightly bound. A more pure implementation might have views registering as observers to their controllers--and the controllers simply broadcast notifications without any knowledge about the views at all. However, from a pragmatic point of view, Apple's approach provides a clean separation and logical workflow without over-engineering the application.

The main point, I think, is to keep the view focused on displaying data. It should probably pass responsibility for manipulating, changing or otherwise massaging the data back to either the controller or the model. Some calculations are OK--particularly when their directly related to displaying the data. But, you should look at any non-display functions with suspicion.

As a secondary role, the view also often responds to user interactions. Though, in this case, it almost always acts as a shell--simply passing the data back to the controller to be properly managed. In fact, many times we implement the code to respond to user interactions directly in the controller.

Similarly, the model should focus on maintaining the application's state, and on saving and loading that state.

Does that answer your question?

-Rich-

No problem, I hope I didn't sound too defensive. That wasn't my intent, I think it's always good to examine and question an apps design. Sometimes there's no single, best answer. For Health Beat, I'm torn between moving the graph stats into the model, or leaving it where it is. Moving it to the model would help make that code more reusable, and might more-cleanly separate the responsibilities. On the other hand, I like the fact that I just pass the graph view an array of data, and it figures out what it needs to do to draw the graph. My controller doesn't need to know anything about the graphs internal implementation..

After all, if I change the graph's implementation, then the stats that I need might change. If I seperate the graph stats from the view, then this might force me to make changes to my model and controller as well. I might very well end up with a design where the MVC modules are even more tightly bound together.

As far as creating your own applications goes, I can try to give you some general advice, but a lot of the details are implementation-specific. In iOS, the view controllers typically do most of the heavy work. They pass data to the views, and respond to actions from the views. They are also typically responsible for communicating with the model. In fact, most of the time my root view controller actually creates the model, and then passes it onto any child view controllers in my app.

This typically leads to a design where each scene of information has its own view controller, and each view controller tends to be rather tightly bound to the views that it manages. This is particularly true if you let the view controllers access the values from controls directly. It's often better to create properties for the data you want to pass in and out of a view--though that makes the design a bit more complicated as well.

Together, the view controllers make up the controller module in our MVC design. In a simple app, they may also act as the model. This is especially true for simple utility apps. For example, if your calculator doesn't actually save or load any data, then it might not need a seperate model. You can just let the view controller perform the calculations directly.

With iOS 5 Apple has added The UIDocument class. In many ways, this can be seen as a model controller. This leads to a design where the view controllers talk to the views. The model controllers talk to the model. And he view and model controllers coordinate with each other (sort of a MVCC design, I guess).

Also, the boundaries between the different modules are often fuzzy. For example, anything dealing with a view's screen coordinates is typically a purely view-level implementation detail. However, if I'm creatingn a container controller, that controller may become responsible for laying out the view controllers that it manages. In those cases, the view coordinates may be manage by the view controllers.

Does that help at all?

-Rich-