iPhone - применение MVC, когда иерархия представления имеет параллельную структуру с иерархией модели

Question

У меня есть класс Треугольник. Каждый треугольник имеет три ребра a, b и c, а также три угла angleA, angleB и angleC. В дополнение к размеру (длине или углу) каждый элемент данных также хранит информацию о том, был ли он введен пользователем или рассчитан на основе геометрических связей с другими данными.

В соответствии с моим классом Triangle у меня есть TriangleSidesAndAnglesView. Этот вид имеет шесть подпредставлений - по одному на каждый из углов, и по одному на каждую из сторон. Содержание подпредставлений зависит от информации в классе модели. Все подпредставления принадлежат классу TriangleDatumView.

Информация может проходить в обе стороны. Например, если пользователь вводит что-либо в текстовое поле, соответствующее ребру или углу, введенное значение необходимо передать в модель.

Я пытаюсь понять, как все организовать. Например, должны ли объекты TriangleDatumView содержать ссылки на соответствующие соответствующие члены в классе модели? Должен ли TriangleSidesAndAnglesView хранить таблицу, которой TriangleDatumView соответствует какому объекту модели? Если TriangleDatumView для (скажем) ребра b знает, что отображаемое имя ребра - «b», так что он может каждый раз писать «b =». , , или он получает эту информацию из модели?

Здесь нет ничего принципиально сложного. Задача состоит в том, чтобы все организовать разумным образом.

Спасибо за любую помощь.

Answer 1

Контроллер представления может находиться между моделью и представлением, управляя массивом TriangleView экземпляров. Контроллер добавляет, изменяет и удаляет представления на основе того, что находится в модели, и делает то же самое для экземпляров модели, основанных на изменениях в родительском представлении (ввод в текстовое поле, нажатие и перетаскивание, другие действия пользовательского интерфейса и т. Д.).

Answer 2

Я задаю себе вопрос: «Что я хочу, чтобы иметь возможность самостоятельно варьировать?» То есть, если у меня есть модель, могу ли я представить совершенно другую реализацию того же интерфейса или совершенно другое представление для той же модели. В тех вариациях, которые меня волнуют, что и где должно быть.

Итак, если метки всегда A, B и C - я не вижу смысла хранить метки в модели. Если они могут измениться, то да, вам не следует жестко их кодировать в представлении.

Представления в MVC часто имеют ссылки на модель, которую они просматривают. Иногда контроллер является посредником. Модели обычно не должны содержать ссылок на представления, а вместо этого использовать такие вещи, как делегаты, для оповещения об изменениях в их состоянии.

Я нахожусь в лагере "Делай самое простое, что работает, и не повторяй себя, рефакторинг при необходимости". Проблема с созданием сложности в начале заключается в том, что она может быть сложной на неправильной оси - пусть функции определяют, как будут развиваться интерфейсы.