Дизайн MVC в какао - все 3 всегда необходимо? Также: соглашения об именах, где поставить контроллер

Question

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

Мой главный вопрос: нужны ли M, V и C, чтобы делать это правильно? Я не видел, чтобы кто-нибудь обращался к этому во всем, что я читал. Примеры (я работаю в Cocoa/Obj-c, хотя это не должно иметь большого значения).

1) Если у меня есть простой образ на моем графическом интерфейсе или поле ввода текста, предназначенное только для удобства пользователя и не сохраняются или не изменяются, они оба будут V (просмотр), но нет M (никаких данных и обработки домена не происходит), и нет C для их объединения. Так что у меня есть некоторые аспекты, которые являются «V» - кажется прекрасным

2) У меня есть два разных и видимых окна, каждая из которых имеет на них кнопку с надписью «ACTIVATE FOO» - когда пользователь нажимает кнопку на любом из них, обе кнопки нажимают и меняют, чтобы сказать «DEACTIVATE FOO», и появляется третье окно с меткой «FOO». Нажатие кнопки снова изменит кнопку в обоих окнах на «АКТИВИРОВАТЬ FOO» и удалит третье окно «FOO». В этом случае мой V состоит из кнопок на обоих окнах, и я думаю, что и третье окно (возможно, все 3 окна). У меня определенно есть C, мой объект Controller будет знать об этих кнопках и окнах, получит клики и удерживает общие состояния относительно окон и кнопок. Однако, есть ли у меня 1 кнопка или кнопка 10, мое окно называется «FOO», или мое окно называется «BAR», это не имеет значения. Здесь нет знаний или данных о домене - просто контролируйте представления. Итак, в этом примере у меня действительно есть «V» и «C», но нет «M» - это нормально?

3) Последний пример, в котором я работаю максимально. У меня есть поле ввода текста как мой вид. Когда я вводю текст в этом, скажем, число, представляющее гравитацию, я держу его в Модели, которая может делать такие вещи, как вычисление физики шара, принимая во внимание мой параметр силы тяжести. Здесь у меня есть V и M, но я не понимаю, почему мне нужно добавить C - контроллер просто примет сигналы от View и передаст их вместе с Model, и наоборот. Быть, так как C - это просто сквозная передача, это действительно «мусорный» код и, по моему мнению, делает невозможным повторное использование. В большинстве ситуаций, когда что-то меняется, мне нужно будет изменить C и M практически одинаковыми способами. Я понимаю, что это, вероятно, ошибка начинающего MVC, чтобы думать, что большинство ситуаций требуют только V и M .. приводит меня к следующему вопросу

4) В Cocoa/Xcode/IB я полагаю, что мои контроллеры всегда должны быть экземпляром объекта в IB? То есть, я кладу все мои компоненты «V» в IB, и для каждой коллекции объектов View (вещи, которые связаны) у меня должен быть экземпляр-контроллер? И тогда, возможно, мои модели НЕ должны быть найдены в IB, а вместо этого найдены только как классы в Xcode, которые связаны с найденным там кодом контроллера. Это точно? Это может объяснить, почему у вас есть контроллер, который на самом деле не добавляет ценности, потому что вы сохраняете согласованность.

5) Как насчет того, чтобы называть эти вещи - для моего вышеприведенного примера о FOO/BAR может быть что-то, что заканчивается контроллером будет C, как FancyWindowOpeningController и т. д.? И для моделей - следует ли суффиксу их с помощью GravityBallPhysicsModel и т. Д., Или я должен просто называть те, что мне нравится? Я не видел достаточно кода, чтобы узнать, что там в дикой природе, и я хочу попасть на правильный путь раньше на

Заранее благодарю за то, что вы меня прямо или даете мне знать. Я на правильном пути. Я чувствую, что я начинаю это получать, и большинство из того, что я говорю здесь, имеет смысл, но проверка моих предположений поможет мне чувствовать себя уверенно.

Answer 1

Я думаю, что все ваши примеры путают отдельные операции/функции с общим приложением дизайн.Итак, общий ответ на все ваши вопросы заключается в том, что нет, каждая операция или функция приложения не должна использовать все три компонента MVC.

Настоящая цель дизайна MVC - сделать каждый компонент модульным и автономным в максимально возможной степени. Поэтому, требуя, чтобы каждая операция каждого компонента включала все три компонента MVC, в первую очередь побеждала бы цель шаблона проектирования.

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

Вам вопросы:

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

(2) Вам не нужна модель в этом случае, потому что вы ничего не моделируете. Модель представляет собой представление данных какого-либо физического объекта или действия. Если окна и элементы управления не отображают репрезентативные данные, то они не нуждаются в модели. Они просто рисуют себя.

(3) Вам нужен контроллер, поэтому вам не нужно переписывать модель или представление каждый раз, когда вы вносите изменения в другой. Это маловероятно в небольших проектах, но как только вы получаете один с несколькими различными интерфейсами (интерфейс, сеть, операции с дисками и т. Д.) И множество различных способов представления в каждом интерфейсе, привязка представления к модели прерывается в спешке.

(4) Если у вас нет контроллера, ваша модель должна иметь ссылки на каждый вид. Система nib использует контроллер как объект, который управляет другими объектами в nib. Вы должны иметь иерархический объект, и владелец файла выполняет эту роль.

(5) Чем длиннее и более описательное название, тем лучше. Через полгода, когда вы вернетесь на техническое обслуживание, вы не запомните, какое окно «WindowOpeningController» открывается или что-то особенное.

Лучший способ оценить MVC - это отступить и подумать о действительно больших, действительно сложных, постоянно развивающихся приложениях. Затем добавьте повторное использование компонентов в разных приложениях. Затем добавьте отладку каждого компонента. Быстро становится понятно, почему это отличный дизайн.