В MVC Модель слепа по отношению к своей среде, представление также может быть - передавая (вслепую) свои события контроллеру, который знает больше о представлении и модели. Поэтому, когда все сказано и сделано, контроллер является «одноразовой» одноразовой частью системы, поскольку он является компонентом, наиболее учитывающим контекст.
если я изменил модель таким образом, что это влияет на контроллер ...
Модель должна предоставлять простые методы CRUD таким образом, чтобы те, кто использует методы, не должны были ничего знать ни о переданном объекте обновления, ни о том, что в действительности происходит внутри модели.
Это означает, что представление, IMO, должно выполнить небольшую работу, создав пропущенную запись, поскольку предполагается, что контроллеры не сохраняют состояние, а представление является более постоянным. Контроллеры срабатывают и запускаются, выполняя свою работу с переданным объектом и не имеют состояния.
Переданные данные создаются в соответствии с неким общим соглашением.
Отпусти меня еще дальше. Предположим, у вас есть представление, сетка таблицы и элемент управления, чье включенное свойство зависит от элемента, выбранного в сетке - вы МОЖЕТЕ создать представление, которое обрабатывает как эти элементы управления, так и эту логику внутренне, и это, вероятно, будет подход в таком упрощенном примере.
Но чем более атомарны ваши представления, тем больше они могут использоваться повторно, поэтому вы создаете представление для каждого, да для каждого элемента управления. Теперь вы смотрите на ситуацию, когда представления должны знать друг о друге, чтобы зарегистрироваться для получения правильного уведомления ...
Это - то, где контроллер входит, так как мы хотим прикрепить все эти зависимости к нему, долгосрочному одноразовому. Таким образом, контроллер управляет этим типом схемы уведомлений от просмотра к просмотру.
Теперь ваши взгляды невежественны, поскольку они могут быть и независимы, поэтому могут использоваться повторно.
Вы можете кодировать представление, не зная о системе или «бизнес-логике», как им нравится ее называть. Вы можете кодировать модель, не зная слишком много о своих целях (хотя это помогает настроить модель, чтобы она могла возвращать наборы данных, которые вы имеете в виду) .... но контроллеры, они последние, и вы должны иметь предыдущие два укрепились прежде, чем вы сможете соединить все вместе.
Вот еще одна вещь, о которой стоит подумать - точно так же, как Модель должна абстрагироваться и предоставить общий интерфейс для базовой реализации данных, которыми она управляет (клиент не знает, поступают ли данные из БД , файл, настройки программы и т. д.) - представление также должно абстрагироваться от используемого элемента управления.
Итак, в конечном итоге это означает, что представление не должно (предостережение ниже) иметь функции / свойства, которые выглядят следующим образом:
public property BackgroundColor{get;set}
Нор
public function ScrollBy(x,y){}
Но вместо этого:
public SetProp(string name, object val){}
И
public DoCmd(string name, object val){}
Это немного надумано, и помните, что я в конечном итоге сказал ... и вы спросите, почему это хорошая идея?
Имея в виду возможность повторного использования, учтите, что однажды вы захотите перенести вещи из WinForms, скажем, в Flex, или просто захотите использовать новую библиотеку управления, которая может не предоставлять такие же возможности.
Я говорю здесь «порт», но это на самом деле не цель, мы не озабочены портированием ЭТОГО конкретного приложения, а наличием базовых элементов MVC, достаточно общих для переноса на новый вкус - внутренне, оставляя согласованный и независимый от возможностей внешний интерфейс не поврежден.
Если вы этого не сделали, то, когда придет ваш новый аромат, все ваши жесткие ссылки для просмотра свойств в (потенциально многократно используемых / изменяемых / расширяемых) контроллерах должны быть отброшены.
Это не означает, что такие общие сеттеры и cmds должны быть интерфейсом для всех ваших возможностей представлений, скорее они должны обрабатывать свойства 'case case', а также обычные props / cmds, которые вы можете выставить в традиционном харде. путь Думайте об этом как о обработчике «расширенных свойств».
Таким образом, (придумано еще раз), предположим, что вы строите каркас, в котором у ваших кнопок больше нет свойства buttonIcon. Это круто, потому что у вас было предвидение, чтобы создать интерфейс представления кнопок, где buttonIcon является расширенным свойством, а внутри представления ваш условный код теперь не выполняет операции, когда получает set / get.
Итак, я пытаюсь сказать, что целью MVC в области кодирования должно быть предоставление универсальных интерфейсов Model и View их базовым компонентам, поэтому, когда вы кодируете контроллер, вам не нужно задумываться о том, кто вы контролируете И хотя Контроллеры (казалось бы, несправедливо) настроены быть жертвенным агнцем в долгосрочной перспективе повторного использования - это не означает, что ВСЕ ваши контроллеры предназначены для смерти.
Они, как мы надеемся, маленькие, так как большая часть их «мышления» была перенесена в полуинтеллектуальные Модели и Представления и другие контроллеры (например: Контроллер для сортировки сетки или управления TreeView) - поэтому, будучи маленькими, они могут быть легко проверенным и пригодным для повторного использования в вашем следующем проекте - или клонироваться и настраиваться, чтобы стать подходящим.