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

Question

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

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

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

2) У меня есть 2 разных видимых окна, каждое из которых имеет кнопку с надписью «ACTIVATE FOO» - когда пользователь нажимает кнопку налибо обе кнопки нажимаются и меняются на «ДЕАКТИВИТЬ FOO», и появляется третье окно с меткой «FOO».Повторное нажатие кнопки изменит кнопку в обоих окнах на «ACTIVATE 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, я думаю, мои контроллеры всегда должны быть созданыобъект в ИБ?То есть я кладу все свои компоненты "V" в IB, и для каждой коллекции объектов View (вещей, которые связаны) у меня должен быть экземплярный контроллер?И тогда, возможно, мои Модели НЕ должны быть найдены в IB, а вместо этого могут быть найдены только как классы в Xcode, которые связаны с найденным там кодом Контроллера.Это точно?Это может объяснить, почему у вас есть контроллер, который на самом деле не добавляет ценности - потому что вы сохраняете согласованность ..

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

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

Answer 1

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

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

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

Ваши вопросы:

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

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

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

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

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

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