MVC - это контролируемая среда, а MVVM - реактивная среда.
В контролируемой среде у вас должно быть меньше кода и общего источника логики; который всегда должен жить в контроллере. Тем не мение; в веб-мире MVC легко разделяется на логику создания представления и динамическую логику представления. Творение живет на сервере, а динамическое - на клиенте. Вы часто это видите в ASP.NET MVC в сочетании с AngularJS, тогда как сервер создаст View, передаст модель и отправит ее клиенту. Затем клиент будет взаимодействовать с представлением, и в этом случае AngularJS станет локальным контроллером. После отправки Модель или новая Модель передаются обратно на контроллер сервера и обрабатываются. (Таким образом, цикл продолжается, и есть много других переводов этой обработки при работе с сокетами или AJAX и т. Д., Но по всей архитектуре идентична.)
MVVM - это реактивная среда, означающая, что вы обычно пишете код (например, триггеры), который активируется на основе какого-либо события. В XAML, где процветает MVVM, все это легко сделать с помощью встроенной инфраструктуры привязки данных, НО, как уже упоминалось, это будет работать на любой системе в любом View с любым языком программирования. Это не специфично для MS. ViewModel срабатывает (обычно это событие изменено свойством), и View реагирует на него в зависимости от того, какие триггеры вы создаете. Это может быть техническим, но суть в том, что представление не имеет состояния и не имеет логики. Это просто меняет состояние на основе значений. Кроме того, ViewModels не имеют состояния с очень малой логикой, а Модели - это Состояние с по существу нулевой логикой, поскольку они должны только поддерживать состояние. Я описываю это как состояние приложения (Модель), транслятор состояния (ViewModel), а затем визуальное состояние / взаимодействие (View).
В настольном или клиентском приложении MVC у вас должна быть Модель, а Модель должна использоваться Контроллером. В зависимости от модели контроллер изменит вид. Представления обычно привязаны к контроллерам с интерфейсами, чтобы контроллер мог работать с различными представлениями. В ASP.NET логика для MVC немного обратная на сервере, поскольку контроллер управляет моделями и передает модели в выбранное представление. Затем представление заполняется данными, основанными на модели, и имеет собственную логику (обычно это другой набор MVC, например, сделанный с AngularJS). Люди будут спорить и путать это с приложением MVC и пытаться сделать и то, и другое, и в этот момент обслуживание проекта в конечном итоге станет катастрофой. ВСЕГДА размещайте логику и управление в одном месте при использовании MVC. НЕ пишите логику представления в коде позади представления (или в представлении через JS для сети) для размещения данных контроллера или модели. Позвольте Контроллеру изменить Вид. ЕДИНСТВЕННАЯ логика, которая должна жить в представлении, - это все, что требуется для создания и запуска через интерфейс, который он использует. Примером этого является предоставление имени пользователя и пароля. Будь то рабочий стол или веб-страница (на клиенте), контроллер должен обрабатывать процесс отправки всякий раз, когда в представлении запускается действие «Отправить». Если все сделано правильно, вы всегда можете легко найти путь к веб-сайту или локальному приложению MVC.
MVVM лично мой фаворит, поскольку он полностью реактивен. Если модель меняет состояние, ViewModel слушает и переводит это состояние, и все! Затем View прослушивает ViewModel на предмет изменения состояния, а также обновляется на основе перевода из ViewModel. Некоторые люди называют это чистым MVVM, но на самом деле есть только один, и мне все равно, как вы спорите, и это всегда Pure MVVM, где View не содержит абсолютно никакой логики.
Вот небольшой пример. Допустим, вы хотите, чтобы меню нажималось при нажатии кнопки. В MVC у вас будет действие MenuPressed в вашем интерфейсе. Контроллер узнает, когда вы нажмете кнопку «Меню», а затем попросите «Вид» скользить в меню на основе другого метода интерфейса, такого как SlideMenuIn. По какой причине? Incase Controller решает, что вы не можете или хотите заняться чем-то другим, вот почему. Контроллер должен отвечать за представление, а представление ничего не делает, если только контроллер не говорит об этом. ТЕМ НЕ МЕНИЕ; в MVVM слайд-меню в анимации должно быть встроенным и общим, и вместо того, чтобы указывать на его вставку, оно будет основано на некотором значении. Так что он слушает ViewModel, и когда ViewModel говорит, IsMenuActive = true (или, тем не менее), анимация для этого имеет место. Теперь, с учетом сказанного, я хочу сделать еще одно замечание, ДЕЙСТВИТЕЛЬНО ЯСНОЕ и ПОЖАЛУЙСТА, обратите внимание. IsMenuActive, вероятно, BAD MVVM или ViewModel дизайн. При разработке ViewModel вы никогда не должны предполагать, что View вообще будет иметь какие-либо функции, а просто передавать переведенное состояние модели. Таким образом, если вы решите изменить свой вид, чтобы удалить меню и просто показать данные / опции другим способом, ViewModel не волнует. Так как бы вы управляли меню? Когда данные имеют смысл, вот как. Таким образом, один из способов сделать это - предоставить меню список опций (возможно, массив внутренних ViewModels). Если в этом списке есть данные, Меню знает, что открыть через триггер, если нет, то оно знает, как скрыть через триггер. У вас просто есть данные для меню или нет в ViewModel. НЕ решайте показывать / скрывать эти данные во ViewModel .. просто переведите состояние модели. Таким образом, представление является полностью реактивным и общим и может использоваться во многих различных ситуациях.
Все это, вероятно, не имеет абсолютно никакого смысла, если вы, по крайней мере, немного не знакомы с архитектурой каждого из них и узнаете, что это может быть очень запутанным, так как вы найдете в сети информацию ALOT OF BAD.
Так что ... нужно помнить, чтобы понять это правильно. Решите заранее, как разработать приложение, и придерживайтесь его.
Если вы делаете MVC, что замечательно, то убедитесь, что ваш Контроллер управляем и полностью контролирует ваш View. Если у вас большое представление, подумайте о добавлении элементов управления в представление с разными контроллерами. Просто НЕ каскадируйте эти контроллеры на разные контроллеры. Очень сложно поддерживать. Уделите немного времени и спроектируйте вещи по-отдельности так, чтобы они работали как отдельные компоненты ... И всегда позволяйте контроллеру сообщать модели о фиксации или сохранении хранилища. Идеальная настройка зависимости для MVC в: Вид ← Контроллер → Модель или с ASP.NET (не начинайте) Модель ← Вид ↔ Контроллер → Модель (где Модель может быть одинаковой или полностью отличная Модель от Контроллера до Представления) ... конечно, единственное, что нужно знать о Контроллере в Представлении на данном этапе, это главным образом для ссылки на конечную точку, чтобы знать, где проходить Модель.
Если уТы делаешь MVVM, я благословляю твою добрую душу, но найди время, чтобы сделать это ПРАВО! Не используйте интерфейсы для одного. Пусть ваш вид решит, как он будет выглядеть на основе значений. Поиграйте с данными с видом на макет. Если в итоге у вас есть вид, который показывает вам меню (в соответствии с примером), даже если вы не хотели его в то время, то ХОРОШО. Ваше мнение работает так, как должно, и реагирует, основываясь на значениях, как и должно. Просто добавьте еще несколько требований к своему триггеру, чтобы убедиться, что этого не произойдет, когда ViewModel находится в определенном переведенном состоянии, или подайте команду ViewModel, чтобы очистить это состояние. В вашей ViewModel НЕ удаляйте это с внутренней логикой, как будто вы оттуда решаете, должен ли View его видеть. Помните, что вы не можете предполагать, есть меню или нет в ViewModel. И, наконец, модель должна просто позволить вам изменить и, скорее всего, сохранить состояние. Это где проверка и все будет происходить; Например, если Модель не может изменить состояние, она просто помечает себя как грязную или что-то в этом роде. Когда ViewModel понимает это, он будет переводить то, что грязно, и View тогда поймет это и покажет некоторую информацию через другой триггер. Все данные в представлении могут быть связаны с ViewModel, поэтому все может быть динамическим, только модель и ViewModel не имеют абсолютно никакого представления о том, как представление отреагирует на привязку. На самом деле Модель также не имеет представления о ViewModel. При настройке зависимостей они должны указывать примерно так и только так: View → ViewModel → Model (и примечание здесь ... и это, вероятно, также будет рассмотрено, но мне все равно ... НЕ ПЕРЕДАЙТЕ МОДЕЛЬ В ВИД, если только эта МОДЕЛЬ не является неизменной, в противном случае оберните ее соответствующей моделью ViewModel. В представлении не должен отображаться модельный период. это неправильно.)
Вот мой последний совет ... Посмотрите на хорошо разработанное, но очень простое приложение MVC и сделайте то же самое для приложения MVVM. У одного будет больше контроля с ограниченной или нулевой гибкостью, а у другого - без контроля и неограниченной гибкости.
Контролируемая среда хороша для управления всем приложением из набора контроллеров или (из одного источника), тогда как реактивная среда может быть разбита на отдельные репозитории, абсолютно не имея представления о том, что делает остальная часть приложения. Микро управление против свободного управления.
Если я вас не смутил, попробуйте связаться со мной ... Я не против подробно рассказать об этом с иллюстрациями и примерами.
В конце концов, мы все программисты, и эта анархия живет внутри нас, когда мы кодируем ... Так что правила будут нарушены, теории изменятся, и все это в конечном итоге приведет к отмыванию свиней ... Но когда работая над большими проектами и большими командами, это действительно помогает согласовать шаблон проектирования и обеспечить его соблюдение. Однажды небольшие дополнительные шаги, предпринятые вначале, превратятся в огромные сбережения позже.