MVC: следует напрямую поговорить с моделью?

Ответ 1

Ниже представлено представление зависимостей в классической архитектуре MVC. Вы заметите, что нет стрелки, указывающей на контроллер, потому что это более новое дополнение:

Источник: Архитектуры графического интерфейса

И тогда есть карта зависимостей, которая ближе к тому, что вы обычно увидите в "MVC-фреймворках":

Источник: Пассивное представление

Конфигурация "пассивного представления" - это не часть архитектуры MVC. Хотя он использует те же имена, на самом деле это вариант на MVP pattern (вы можете найти более подробное описание в эта публикация)

В нижней строке: да, если вы используете MVC или MVC-подобную архитектуру, то ваши представления должны запрашивать информацию на уровне модели.

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

В принципе, IMHO, лучший способ назвать Rails-подобные шаблоны - OLT: ORM-Logic-Template.

Ответ 2

"Модель" - ваше основное приложение. Все, что может сделать ваше приложение, - это модель.
"Вид" предназначен для визуализации происходящего и предоставления пользовательского интерфейса.
"Контроллер" - это клей, необходимый для реагирования на события и инструктирования модели и просмотра того, что делать.

Теперь, какие параметры у вас есть для связи между моделью и представлением?

• Push: все данные, которые нужно просмотреть, вставляются в него, как правило, с помощью контроллера.
• Pull: представление получает все необходимые данные из того, где это необходимо.

Второй, очевидно, более самодостаточен. Если вам нужно вставлять данные в представление, это означает, что кто-то за пределами представления должен знать, чего хочет представление. И особенно мнения могут быть довольно динамичными и часто меняться. Кто-то решает отобразить еще один виджет в верхнем правом углу, и внезапно для представления требуется больше данных. Это означает, что другие части необходимо перекодировать, чтобы вставлять больше данных в представление. Поэтому вам нужно изменить как минимум две независимые части только потому, что представление было изменено.

Лучший вариант - дать представлению дескриптор, который позволяет ему разговаривать с моделью и получать все необходимые ей данные. Контроллер просто сообщает, что "нам нужна форма XYZ сейчас, вот ручка, чтобы поговорить с моделью, иди!" и представление может выполнять свою работу.

Ответ 3

Я думаю, что люди перепутали понятия, термины и практики. ТАК ОЧЕНЬ, что сложно даже общаться.

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

Затем их бизнес-уровень объединяется с моделью представления и, следовательно, с уровнем представления...

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

По крайней мере, что я беру на себя это...

Ответ 4

Я думаю, что большинство цитат вокруг MVC в целом нормально, но я предполагаю, что вы говорите о... позволяет быть конкретным и на самом деле называть его... Microsoft View Controller. Поскольку они склонны всегда добавлять свой собственный немного (и хотя многие не согласны, на мой взгляд, я думаю, что в большинстве своем их намерения хорошо сформированы, но это дискуссия по другой теме).

Я просто хотел подчеркнуть, что Microsoft-View-Controller на самом деле является другим вариантом в теме Model-View-Controller.

Я использую его следующим образом:

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

• MVC (любой вариант) - это методология для разработки, которая предназначена для расширения и обслуживания.
• В Microsoft-VC нет возможности подключить представление к нескольким моделям (если вы не используете ViewModels). Эта практика поощряется, и проблемы безопасности, связанные с подключением непосредственно к задним моделям, изобилуют. Так или нет, его общепринятая плохая практика заключается в непосредственном подключении представлений к моделям, и вместо этого вы должны подключать их к ViewModels.

MVC - это многоуровневая архитектура. Так сложите его. Под этим я подразумеваю, что EF выполняет свою работу по сопоставлению таблиц с классами и оставляет их в покое. Microsoft-VC заставляет людей применять шаблон дизайна (принцип Open/Close) к модели путем автоматического генерации кода с использованием классов "Partial". Таким образом, вы создаете свой собственный пустой частичный класс, а затем добавляете к нему свои метаданные. Это не очень хорошая идея добавить код здесь, поскольку он тесно связан с моделью. Вместо того, чтобы...

Добавить уровень репозитория с использованием шаблона репозитория. Это использует все ваши классы моделей, чтобы сделать базовый (очень простой) CRUD. Тогда...

Добавить уровень домена (бизнес) и заставить его вызвать уровень репо, чтобы получить данные, необходимые для выполнения бизнес-правил... Затем...

Подключите свои контроллеры только к бизнес-уровням и используйте инструмент, например automapper, для сопоставления данных, возвращаемых с уровня домена, для просмотра моделей для ваших просмотров.

По мере развития опыта вы можете впоследствии добавить интерфейсы между слоями по мере необходимости и легко применить хорошо известный шаблон IOC с помощью какой-либо формы DI.

Надеюсь, это поможет... Но в целом тот факт, что MVC является многоуровневой архитектурой, означает, что добавление слоев - это то, что он предназначен для этого, не ограничивает себя только тем, что работает с одним способом. Также помните, если вы слышите, как люди говорят, что многоуровневая архитектура N-Tier для больших систем - это просто глупо... каждая система - большая система. Ни один бизнес не инвестирует потенциально по меньшей мере 100 тысяч для разработки небольшой системы и оставляет ее на этом (я знаю, что мне платят большие деньги за разработку таких систем на основе моей зарплаты в одиночку и налогов, которые работодатель должен платить выше и выше моя зарплата, я могу с уверенностью сказать, что любая компания, в которой работает более 2 разработчиков, уже прошла за 100 тыс. долларов в год на разработку так называемых "малых" систем). Все системы предназначены для роста, и чем раньше вы примете этот подход, тем легче будет поддерживать и расширять вашу систему.