iPhone -- Applying MVC when the view hierarchy has a parallel structure to the model hierarchy

I have a Triangle class. Each Triangle has three edges a, b, and c, and also three angles angleA, angleB, 开发者_如何学运维and angleC. In addition to the size (length or angle), each datum also stores whether it was entered by the user or was calculated based on geometric relationships to other data.

Corresponding to my Triangle class, I have a TriangleSidesAndAnglesView. This view has six subviews -- one for each of the angles, and one for each of the sides. The contents of the subviews depends on the information in the model class. The subviews are all of class TriangleDatumView.

Information can pass both ways. For example, if the user enters something in a text field corresponding to an edge or angle, the entered value needs to be passed up to the model.

I am trying to figure out how to keep everything organized. For example, should the TriangleDatumView objects contain references to the respective corresponding members in the model class? Does the TriangleSidesAndAnglesView need to keep a table of which TriangleDatumView corresponds to what model object? Should the TriangleDatumView for (say) edge b know that the name of the edge it is displaying is "b" so that it can write "b=" each time . . . or does it grab that info from the model?

Nothing here is fundamentally difficult. The challenge is organizing it all in a sensible way.

Thanks for any help.

A question I ask myself is "What do I want to be able to independently vary?" -- meaning, if I have a model, could I imagine a totally different implementation of the same interface or a totally different view for the same model. In the variations that I care about, what needs to be where.

So, if labels are always A, B, and C -- I see no reason to store labels in the model. If they can change, then yes, you should not hard-code them in the view.

Views in MVC often have references right to the model they are viewing. Sometimes the controller is an intermediary. Models should usually not contain references to views -- but instead use things like delegates to alert of changes to their state.

I'm in the "Do the simplest thing that works, and don't repeat yourself, refactor when necessary" camp. The issue with building in the complexity at the start is that it might be complex on the wrong axis -- let the features dictate how the interfaces grow.

A view controller could sit between model and view, managing an array of TriangleView instances. The controller adds, modifies and deletes views based on what is in the model, and does the same for model instances based upon changes to the parent view (typing in a text field, tapping and dragging, and other UI actions, etc.).