В чем разница между MVC и MVVM? [закрыто]

Есть ли разница между стандартным шаблоном «Model View Controller» и шаблоном Microsoft Model / View / ViewModel?

MVC / MVVM не является или / или выбором.

Эти два шаблона по-разному возникают как при разработке ASP.Net, так и Silverlight / WPF.

Для ASP.Net MVVM используется для двустороннего связывания данных в представлениях. Обычно это реализация на стороне клиента (например, с использованием Knockout.js). MVC, с другой стороны, является способом разделения проблем на стороне сервера .

Для Silverlight и WPF, шаблон MVVM более всеобъемлющий и может появиться в качестве замены для MVC (или других форм организации программного обеспечения в отдельные обязанности). Одно предположение, что часто выходили из этого рисунка, в том , что ViewModelпросто заменить контроллер в MVC(как если бы вы могли бы просто заменить VMна Cв аббревиатуре , и все будет прощено) ...

ViewModel не обязательно заменяет необходимость в отдельных контроллерах.

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

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

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

Из того, что мы видели до сих пор, основное преимущество шаблона ViewModel заключается в удалении кода из кода XAML, что делает редактирование XAML более независимой задачей . Мы по-прежнему создаем контроллеры, когда и когда это необходимо, чтобы контролировать (без каламбура) общую логику наших приложений.

Основные рекомендации MVCVM, которым мы следуем:

• Представления отображают определенную форму данных . Они понятия не имеют, откуда поступают данные.
• Модели представления содержат определенную форму данных и команд , они не знают, откуда поступают данные или код или как они отображаются.
• Модели содержат фактические данные (различные контексты, хранилища или другие методы).
• Контроллеры прослушивают и публикуют события. Контроллеры предоставляют логику, которая контролирует, какие данные видны и где. Контроллеры предоставляют код команды для ViewModel, так что ViewModel фактически можно использовать повторно.

Мы также отметили, что платформа Sculpture code-gen реализует MVVM и шаблон, похожий на Prism, а также широко использует контроллеры для разделения всей логики варианта использования.

Не думайте, что контроллеры становятся устаревшими с помощью View-моделей.

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

Дополнительным преимуществом использования модели MVCVM является то, что в течение жизни приложения в памяти должны существовать только объекты контроллера, а контроллеры содержат в основном код и мало данных о состоянии (например, небольшие накладные расходы памяти). Это делает приложения, требующие меньше памяти, чем решения, для которых необходимо сохранять модели представлений, и идеально подходит для определенных типов мобильных разработок (например, Windows Mobile с использованием Silverlight / Prism / MEF). Это, конечно, зависит от типа приложения, так как вам, возможно, все равно придется сохранять время от времени кэшированные виртуальные машины для отзывчивости.

Примечание. Это сообщение редактировалось много раз и не предназначалось специально для узкого задаваемого вопроса, поэтому я обновил первую часть, чтобы теперь также охватывать его. Большая часть обсуждения в комментариях ниже относится только к ASP.Net, а не к более широкой картине. Этот пост был призван охватить более широкое использование MVVM в Silverlight, WPF и ASP.Net и попытаться отговорить людей от замены контроллеров на ViewModels.

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

По мере усложнения в середине 2000-х шаблон проектирования программного обеспечения MVC, который впервые был описан в 1970-х годах, начал применяться к веб-приложениям. Подумайте базы данных, HTML-страницы и промежуточный код. Давайте немного уточним это, чтобы получить MVC: для «базы данных», давайте предположим, что база данных плюс интерфейсный код. Для »HTML-страниц« давайте предположим, что HTML-шаблоны плюс код обработки шаблонов. Для «кода между», давайте предположим, что код отображает клики пользователей на действия, которые могут повлиять на базу данных, определенно вызывая отображение другого представления. Вот и все, по крайней мере, для целей этого сравнения.

Давайте сохраним одну особенность этого веб-материала, не так, как сегодня, а так, как он существовал десять лет назад, когда JavaScript был скромным, презренным раздражением, от которого неплохо справлялись настоящие программисты: HTML-страница по сути глупа и пассивна , Браузер - тонкий клиент или, если хотите, плохой клиент. В браузере нет интеллекта. Правило перезагрузки полной страницы. »Представление« создается каждый раз заново.

Давайте помнить, что этот веб-путь, несмотря на всю свою ярость, был ужасно отсталым по сравнению с рабочим столом. Настольные приложения - толстые клиенты или богатые клиенты, если хотите. (Даже такую ​​программу, как Microsoft Word, можно рассматривать как своего рода клиента, клиента для документов.) Это клиенты, полные интеллекта, полные знаний о своих данных. Они с состоянием. Они кэшируют данные, которые обрабатывают в памяти. Нет такого дерьма, как полная перезагрузка страницы.

И этот богатый настольный способ, вероятно, является источником второй аббревиатуры, MVVM. Не обманывайтесь буквами, пропуском C. Контроллеры все еще там. Они должны быть. Ничто не удаляется. Мы просто добавляем одну вещь: отслеживание состояния, данные, кэшированные на клиенте (и вместе с этим интеллект для обработки этих данных). Эти данные, по сути кеш клиента, теперь называются «ViewModel». Это то, что позволяет богатую интерактивность. И это все.

• MVC = модель, контроллер, вид = по существу односторонняя связь = плохая интерактивность
• MVVM = модель, контроллер, кэш, представление = двусторонняя связь = богатая интерактивность

Мы видим, что с Flash, Silverlight и, что наиболее важно, с JavaScript, веб охватил MVVM. Браузеры больше не могут по праву называться тонкими клиентами. Посмотрите на их программируемость. Посмотрите на их потребление памяти. Посмотрите на все интерактивность Javascript на современных веб-страницах.

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

MVVM Model-View ViewModel похож на MVC, Model-View Controller

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

Рассел Ист ведет блог, обсуждая более подробно Почему MVVM отличается от MVC

С одной стороны, MVVM - это прогрессия шаблона MVC, который использует XAML для обработки отображения. Эта статья обрисовывает в общих чертах некоторые из двух аспектов.

Основная идея архитектуры Model / View / ViewModel заключается в том, что поверх данных («Модель») есть еще один слой невизуальных компонентов («ViewModel»), которые более точно отображают концепции данных. понятиям представления данных («представление»). Это ViewModel, к которому привязывается View, а не Модель напрямую.

Microsoft предоставила объяснение паттерна MVVM в среде Windows здесь .

Вот важный раздел:

В шаблоне проектирования Model-View-ViewModel приложение состоит из трех основных компонентов.

• Модель : представляет модель данных, которую использует ваше приложение. Например, в приложении для обмена изображениями этот слой может представлять набор изображений, доступных на устройстве, и API, используемый для чтения и записи в библиотеку изображений.

• Представление : приложение обычно состоит из нескольких страниц пользовательского интерфейса. Каждая страница, показанная пользователю, является представлением в терминологии MVVM. Представление - это код XAML, используемый для определения и стилизации того, что видит пользователь. Данные из модели отображаются пользователю, и задача ViewModel состоит в том, чтобы передать UI эти данные в зависимости от текущего состояния приложения. Например, в приложении для обмена изображениями представления будут представлять собой пользовательский интерфейс, который показывает пользователю список альбомов на устройстве, изображения в альбоме и, возможно, другой, который показывает пользователю конкретное изображение.

• ViewModel : ViewModel связывает модель данных или просто модель с пользовательским интерфейсом или представлениями приложения. Он содержит логику, с которой можно управлять данными из модели, и предоставляет данные в виде набора свойств, с которыми пользовательский интерфейс или представления XAML могут быть связаны. Например, в приложении для обмена изображениями ViewModel предоставляет список альбомов, а для каждого альбома - список изображений. Пользовательский интерфейс не зависит от того, откуда берутся картинки и как они извлекаются. Он просто знает набор картинок, представленных ViewModel, и показывает их пользователю.

Я думал, что одно из основных отличий заключается в том, что в MVC ваш V читает ваш M напрямую и проходит через C для манипулирования данными, тогда как в MVVM ваша VM действует как прокси-сервер M, а также предоставляет вам доступную функциональность. V.

Если я не полон мусора, я удивляюсь, что никто не создал гибрид, где ваша виртуальная машина является просто прокси-сервером M, а C предоставляет все функциональные возможности.

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. Будь то рабочий стол или веб-страница (на клиенте), контроллер должен обрабатывать процесс отправки всякий раз, когда в представлении запускается действие «Отправить». Если все сделано правильно, вы всегда можете легко разобраться в веб-приложении или локальном приложении MVC. Будь то рабочий стол или веб-страница (на клиенте), контроллер должен обрабатывать процесс отправки всякий раз, когда в представлении запускается действие «Отправить». Если все сделано правильно, вы всегда можете легко разобраться в веб-приложении или локальном приложении 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 является View ← Контроллер → Модель или с ASP.NET (не заводите меня) Модель ← Вид ↔ Контроллер → Модель (где Модель может быть той же или совершенно другой Моделью от Контроллера до Представления) ... конечно, единственное, что нужно знать о Controller in View на данный момент, это в основном информация конечной точки. где обратно пройти модель.

Если вы делаете MVVM, я благословляю вашу добрую душу, но найдите время, чтобы сделать это прямо! Не используйте интерфейсы для одного. Пусть ваш вид решит, как он будет выглядеть на основе значений. Поиграйте с данными с видом на макет. Если в итоге у вас есть вид, который показывает вам меню (в соответствии с примером), даже если вы не хотели его в то время, то ХОРОШО. Ваше мнение работает так, как должно, и реагирует, основываясь на значениях, как и должно. Просто добавьте еще несколько требований к своему триггеру, чтобы убедиться, что этого не произойдет, когда ViewModel находится в определенном переведенном состоянии, или подайте команду ViewModel, чтобы очистить это состояние. В вашей ViewModel НЕ удаляйте это с внутренней логикой, как будто вы оттуда решаете, должен ли View его видеть. Помните, что вы не можете предполагать, есть меню или нет в ViewModel. И наконец, Модель должна просто позволить вам изменить и, скорее всего, сохранить состояние. Это где проверка и все будет происходить; например, если Модель не может изменить состояние, она просто помечает себя как грязную или что-то в этом роде. Когда ViewModel понимает это, он будет переводить то, что грязно, и View тогда поймет это и покажет некоторую информацию через другой триггер. Все данные в представлении могут быть связаны с ViewModel, поэтому все может быть динамическим, только модель и ViewModel не имеют абсолютно никакого представления о том, как представление отреагирует на привязку. На самом деле Модель также не имеет представления о ViewModel. При настройке зависимостей они должны указывать как так и только так Если вы не измените состояние, оно будет просто помечено как грязное или что-то в этом роде. Когда ViewModel понимает это, он будет переводить то, что грязно, и View тогда поймет это и покажет некоторую информацию через другой триггер. Все данные в представлении могут быть связаны с ViewModel, поэтому все может быть динамическим, только модель и ViewModel не имеют абсолютно никакого представления о том, как представление отреагирует на привязку. На самом деле Модель также не имеет представления о ViewModel. При настройке зависимостей они должны указывать как так и только так Если вы не измените состояние, оно будет просто помечено как грязное или что-то в этом роде. Когда ViewModel понимает это, он будет переводить то, что грязно, и View тогда поймет это и покажет некоторую информацию через другой триггер. Все данные в представлении могут быть связаны с ViewModel, поэтому все может быть динамическим, только модель и ViewModel не имеют абсолютно никакого представления о том, как представление отреагирует на привязку. На самом деле Модель также не имеет представления о ViewModel. При настройке зависимостей они должны указывать как так и только так Все данные в представлении могут быть связаны с ViewModel, поэтому все может быть динамическим, только модель и ViewModel не имеют абсолютно никакого представления о том, как представление отреагирует на привязку. На самом деле Модель также не имеет представления о ViewModel. При настройке зависимостей они должны указывать как так и только так Все данные в представлении могут быть связаны с ViewModel, поэтому все может быть динамическим, только модель и ViewModel не имеют абсолютно никакого представления о том, как представление отреагирует на привязку. На самом деле Модель также не имеет представления о ViewModel. При настройке зависимостей они должны указывать как так и только такView → ViewModel → Model (и примечание здесь ... и это, вероятно, также будет обсуждаться, но мне все равно ... НЕ ПЕРЕДАЙТЕ МОДЕЛЬ В ВИД, если эта модель не является неизменной; в противном случае оберните ее правильная ViewModel. Представление не должно видеть модельный период. Я даю крысам взлом, какую демонстрацию вы видели или как вы это сделали, это неправильно.)

Вот мой последний совет ... Посмотрите на хорошо разработанное, но очень простое приложение MVC и сделайте то же самое для приложения MVVM. Один будет иметь больше контроля с ограниченной или нулевой гибкостью, а другой не будет иметь контроля и неограниченной гибкости.

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

Если я вас не смутил, попробуйте связаться со мной ... Я не против подробно рассказать об этом с иллюстрациями и примерами.

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

Простая разница: (Вдохновленный курсом Яакова Coursera AngularJS)

MVC (модель просмотра контроллера)

1. Модели. Модели содержат информацию о данных. Не вызывает и не использует Controller и View. Содержит бизнес-логику и способы представления данных. Некоторые из этих данных в той или иной форме могут отображаться в представлении. Он также может содержать логику для извлечения данных из некоторого источника.
2. Контроллер: действует как связь между представлением и моделью. Просмотр вызовов Контроллер и Контроллер вызывает модель. Это в основном информирует модель и / или представление о необходимости изменения.
3. Вид: имеет дело с частью пользовательского интерфейса. Взаимодействует с пользователем.

MVVM (модель с видом на модель)

ViewModel :

1. Это представление о состоянии зрения.
2. Он содержит данные, которые отображаются в представлении.
3. Отвечает на просмотр событий, ака логика презентации.
4. Вызывает другие функции для обработки бизнес-логики.
5. Никогда напрямую не просит представление отображать что-либо.

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

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

Если вы работали с MVC, вам, вероятно, иногда было полезно создавать объекты модели, отражающие состояние вашего представления, например, отображать и скрывать некоторые диалоговые окна редактирования и т. Д. В этом случае вы используете модель представления.

Шаблон MVVM - это просто обобщение этой практики для всех элементов пользовательского интерфейса.

И это не шаблон Microsoft, к которому добавляется то, что привязки данных WPF / Silverlight особенно хорошо подходят для работы с этим шаблоном. Но ничто не мешает вам использовать его, например, с лицами java-сервера.

Другие ответы могут быть непростыми для понимания тем, кто не очень знаком с предметом архитектурных моделей. Кто-то, кто является новичком в архитектуре приложения, может захотеть узнать, как его выбор может повлиять на ее приложение на практике и какова суета в сообществах.

Пытаясь пролить свет на вышесказанное, я составил этот сценарий с участием MVVM, MVP и MVC. История начинается с того, что пользователь нажимает кнопку «НАЙТИ» в приложении для поиска фильмов…:

Пользователь: Нажмите ...

Вид : Кто это? [ MVVM | MVP | MVC ]

Пользователь: Я только что нажал на кнопку поиска ...

Вид : Хорошо, подожди секунду ... [ MVVM | MVP | MVC ]

( Представление вызова ViewModel | Presenter | Controller …) [ MVVM | MVP | MVC ]

Вид : Эй, ViewModel | Ведущий | Контроллер , Пользователь только что нажал на кнопку поиска, что мне делать? [ MVVM | MVP | MVC ]

ViewModel | Ведущий | Контролер : Эй, вид , есть ли поисковый запрос на этой странице? [ MVVM | MVP | MVC ]

Вид : Да,… вот оно… «пианино» [ MVVM | MVP | MVC ]

—— Это самое важное различие между MVVM и MVP | MVC ———

Докладчик : Спасибо, View ... пока я ищу поисковый запрос по модели , пожалуйста, покажите ему / ей индикатор выполнения [ MVP | MVC ]

( Ведущий | Контроллер вызывает модель …) [ MVP | MVC ]

ViewController : Спасибо, я буду искать поисковый запрос по модели, но не буду обновлять вас напрямую. Вместо этого я буду инициировать события для searchResultsListObservable, если есть какой-либо результат. Так что тебе лучше наблюдать за этим. [ MVVM ]

(Наблюдая за любым триггером в searchResultsListObservable, View считает, что должен показывать пользователю индикатор выполнения, поскольку ViewModel не будет с ним разговаривать)

------------------------------

ViewModel | Ведущий | Контроллер : Эй, модель , у тебя есть совпадение по этому поисковому запросу: «фортепиано» [ MVVM | MVP | MVC ]

Модель : Эй, ViewModel | Ведущий | Контроллер , дай мне проверить… [ MVVM | MVP | MVC ]

( Модель делает запрос к базе данных фильмов…) [ MVVM | MVP | MVC ]

( Спустя некоторое время … )

———— Это точка расхождения между MVVM , MVP и MVC ————–

Модель : Я нашел список для вас, ViewModel | Ведущий , вот оно в формате JSON «[{« name »:« Piano Teacher »,« year »: 2001}, {« name »:« Piano »,« year »: 1993}]» [ MVVM | MVP ]

Модель : есть некоторый результат, контроллер. Я создал переменную поля в моем экземпляре и заполнил ее результатом. Это имя «searchResultsList» [ MVC ]

( Ведущий | Контроллер благодарит Модель и возвращается к Представлению ) [ MVP | MVC ]

Ведущий : Спасибо за ожидание View , я нашел для вас список подходящих результатов и упорядочил их в презентабельном формате: [«Piano Teacher 2001», «Piano 1993»]. Также, пожалуйста, скройте индикатор прогресса сейчас [ MVP ]

Контроллер : Спасибо за ожидание, View , я спросил модель о вашем поисковом запросе. Он говорит, что нашел список совпадающих результатов и сохранил их в переменной с именем «searchResultsList» внутри своего экземпляра. Вы можете получить это оттуда. Также, пожалуйста, скройте индикатор прогресса сейчас [ MVC ]

ViewModel : Любой наблюдатель в searchResultsListObservable должен быть уведомлен о наличии нового списка в презентабельном формате: [«Piano Teacher 2001», «Piano 1993»]. [ MVVM ]

Просмотр : Большое спасибо Ведущий [ MVP ]

Вид : Спасибо « Controller » [ MVC ] (Теперь View спрашивает себя: Как я должен представить результаты , которые я получаю от модели ? Чтобы пользователь должен год производства фильма пришел первый или последний ...?)

Представление : О, есть новый триггер в searchResultsListObservable…, хорошо, есть презентабельный список, теперь мне нужно только показать его в списке. Я должен также скрыть индикатор выполнения теперь, когда у меня есть результат. [ MVVM ]

В случае , если вы заинтересованы, я написал серию статей здесь , сравнивая MVVM, MVP и MVC, реализовав поиск фильма приложения для Android.

Внедрение строго типизированных моделей представления в представление с использованием MVC

1. Контроллер отвечает за обновление ViewModel и внедрение его в View. (для получения запросов)
2. ViewModel - это контейнер для DataContext и состояния просмотра, такого как последний выбранный элемент и т. Д.
3. Модель содержит сущности БД и очень близка к схеме БД, она выполняет запросы и фильтрацию. (Мне нравятся EF и LINQ для этого)
4. Модель также должна учитывать репозитории и / или проекцию результатов в строгие типы (EF имеет отличный метод ... EF.Database.Select (querystring, parms) для прямого доступа ADO для вставки запросов и получения сильных типов. Это относится к EF медленный аргумент. EF НЕ МЕДЛЕН !
5. ViewModel получает данные и выполняет бизнес-правила и проверку
6. Контроллер на посту обратно будет вызывать метод ViewModel Post и ждать результатов.
7. Контроллер вставит недавно обновленную Viewmodel в View. В представлении используется только строгое связывание типов .
8. Представление просто отображает данные и отправляет события обратно в контроллер. (см. примеры ниже)
9. MVC перехватывает входящий запрос и направляет его на соответствующий контроллер с сильным типом данных

В этой модели больше нет контакта уровня HTTP с объектами запроса или ответа, так как машина MVC MSFT скрывает это от нас.

По разъяснениям пункта 6 выше (по запросу) ...

Предположим ViewModel, как это:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

Метод контроллера из этого поста будет выглядеть следующим образом (см. Ниже), обратите внимание, что экземпляр mvm автоматически создается механизмами привязки MVC. В результате вам никогда не придется опускаться до слоя строки запроса! Это MVC, создающий для вас ViewModel на основе строк запроса!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Обратите внимание, что для того, чтобы этот метод действия, описанный выше, работал так, как вы намеревались, у вас должен быть определен нулевой CTOR, который инициализирует вещи, не возвращенные в посте. Обратная запись также должна отправлять обратно пары имя / значение для тех вещей, которые изменились. Если отсутствуют пары имя / значение, механизм привязки MVC делает правильные вещи, которые просто ничего! Если это произойдет, вы, возможно, скажете: «Я теряю данные на почтовых серверах» ...

Преимущество этого шаблона заключается в том, что ViewModel выполняет всю «беспорядочную» работу, взаимодействуя с логикой Model / Buisness, а контроллер является просто своего рода маршрутизатором. Это SOC в действии.

MVVM добавляет модель представления в смесь. Это важно, так как это позволяет вам использовать подход связывания WPF, не прибегая к этим частям пользовательского интерфейса в вашей обычной модели.

Я могу ошибаться, но я не уверен, что MVVM действительно заставляет контроллер вмешиваться. Я считаю, что концепция более соответствует: http://martinfowler.com/eaaDev/PresentationModel.html . Я думаю, что люди предпочитают объединять его с MVC, а не то, что он встроен в шаблон.

Из того, что я могу сказать, MVVM отображается на MV MVC - это означает, что в традиционном паттерне MVC V не связывается напрямую с M. Во второй версии MVC существует прямая связь между M и V. MVVM по-видимому, берет на себя все задачи, связанные со связью M и V, и связывает их, чтобы отделить его от C. По сути, все еще существует более широкий рабочий процесс приложения (или реализация сценариев использования), которые не полностью учитываются в MVVM. Это роль контроллера. Удаляя эти низкоуровневые аспекты из контроллеров, они становятся чище и упрощают изменение сценария использования приложения и бизнес-логики, а также делают контроллеры более пригодными для повторного использования.

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

Ну, обычно MVC используется в веб-разработке, а MVVM наиболее популярен в разработке WPF / Silverlight. Однако иногда веб-архитектура может иметь сочетание MVC и MVVM.

Например: вы можете использовать knockout.js, и в этом случае у вас будет MVVM на стороне клиента. И сторона сервера вашего MVC также может измениться. В сложных приложениях никто не использует чистую модель. Возможно, имеет смысл использовать ViewModel в качестве «Модели» MVC, и ваша настоящая Модель в основном будет частью этой ВМ. Это дает вам дополнительный уровень абстракции.

MVVMC, или, возможно, MVC +, кажется жизнеспособным подходом для предприятия, а также быстрой разработки приложений. Хотя приятно отделить пользовательский интерфейс от бизнес-логики и логики взаимодействия, «чистый» шаблон MVVM и большинство доступных примеров лучше всего работают с единичными представлениями.

Не уверен насчет ваших дизайнов, но большинство моих приложений, тем не менее, содержат страницы и несколько (многократно используемых) представлений, и, следовательно, ViewModels действительно должны взаимодействовать до некоторой степени. Использование страницы в качестве контроллера отрицательно сказалось бы на цели MVVM, поэтому отказ от использования подхода «VM-C» для базовой логики может привести к… ну… сложным конструкциям по мере развития приложения. Даже в VB-6 большинство из нас, вероятно, прекратили кодировать бизнес-логику в событие Button и начали «передавать» команды на контроллер, верно? Я недавно посмотрел на множество новых фреймворков на эту тему; мой любимый, безусловно, подход Magellan (в codeplex). Удачного кодирования!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

Контроллер не заменяется ViewModel в MVVM, потому что ViewModel имеет совершенно другую функциональность, чем Controller. Вам все еще нужен контроллер, потому что без контроллера ваша модель, ViewModel и View не будут иметь большого значения ... В MVVM у вас также есть контроллер, имя MVVM просто вводит в заблуждение.

MVVMC - правильное имя, по моему скромному мнению.

Как вы можете видеть, ViewModel - это просто дополнение к шаблону MVC. Он перемещает логику преобразования (например, преобразовать объект в строку) из контроллера в ViewModel.

Я сделал Среднюю статью для этого.

MVVM

1. View ➡ ViewModel ➡ Модель

   • Представление имеет ссылку на ViewModel, но не наоборот.
   • ViewModel имеет ссылку на модель, но не наоборот.
   • Вид не имеет ссылки на модель и наоборот.

2. Если вы используете контроллер, он может иметь ссылку на Views и ViewModels , хотя Controller не всегда необходим, как продемонстрировано в SwiftUI .

3. Привязка данных : мы создаем прослушиватели для свойств ViewModel.

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

различия в настройке

1. Бизнес-логика хранится в контроллере для MVC и в ViewModels для MVVM.
2. События передаются напрямую из View в контроллер в MVC, а события передаются из View в ViewModel в контроллер (если он есть) для MVVM.

Общие черты

1. И MVVM, и MVC не позволяют представлению отправлять сообщения непосредственно в Model / s.
2. У обоих есть модели.
3. Оба имеют взгляды.

Преимущества МВВМ

1. Поскольку модели представления содержат бизнес-логику, они представляют собой более мелкие конкретные объекты, облегчающие их модульные тесты. С другой стороны, в MVC бизнес-логика находится в ViewController. Как вы можете верить, что модульное тестирование контроллера представления является полностью безопасным без одновременного тестирования всех методов и слушателей? Вы не можете полностью доверять результатам модульных тестов.
2. В MVVM, поскольку бизнес-логика перекачивается из контроллера в атомарные единицы ViewModel, размер ViewController уменьшается, и это делает код ViewController более разборчивым.

Преимущества MVC

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

С практической точки зрения MVC (Model-View-Controller) - это шаблон. Однако MVC при использовании в качестве ASP.net MVC в сочетании с Entity Framework (EF) и «мощными инструментами» является очень мощным, частично автоматизированным подходом для переноса баз данных, таблиц и столбцов на веб-страницу для любого Только операции CRUD или R (извлечение или чтение). По крайней мере, когда я использовал MVVM, модели представлений взаимодействовали с моделями, которые зависели от бизнес-объектов, которые, в свою очередь, были «сделаны вручную», и после долгих усилий удалось получить модели, которые были так же хороши, как и EF. -of коробки». С практической точки зрения программирования, MVC кажется хорошим выбором, потому что он дает много полезных функций, но все еще есть потенциал для добавления наворотов.

В дополнение ко многим приведенным ответам, я хотел добавить дополнительную перспективу из современной клиентской сети - или Rich Web Application .

Действительно, в наши дни простые веб-сайты и более крупные веб-приложения обычно создаются со многими популярными библиотеками, такими как Bootstrap. Построенный Стивом Сандерсоном, Knockout обеспечивает поддержку шаблона MVVM, который имитирует одно из самых важных действий в шаблоне: привязку данных через модель представления. Небольшой JavaScript позволяет реализовать данные и логику, которые затем можно добавить к элементам страницы с помощью простых data-bindатрибутов HTML, аналогично использованию многих функций Bootstrap . Вместе эти две библиотеки предлагают интерактивный контент; и в сочетании с маршрутизацией этот подход может привести к простому, но мощному подходу к созданию одностраничного приложения .

Точно так же современная клиентская структура, такая как Angular, следует соглашению с шаблоном MVC, но также добавляет Сервис. Интересно, что это рекламируется как модель-вид-что угодно (MVW). (См. Этот пост на переполнение стека .)

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

Раньше я думал, что MVC и MVVM одинаковы. Теперь из-за существования Flux я могу сказать разницу:

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

В MVVM у вас также есть модель представления для каждого компонента. Шаблон не определяет, как чертовски представление должно влиять на модель представления, поэтому обычно большинство структур просто включает функциональность контроллера в модель представления. Тем не менее, MVVM говорит вам, что данные вашей модели представления должны поступать из модели, то есть всей модели, которая не знает или не настроена для конкретного представления.

Чтобы продемонстрировать разницу, давайте возьмем образец потока. Шаблон потока рассказывает, как должны взаимодействовать различные представления в приложении. Каждый просмотр прослушивает магазин и запускает действия с помощью диспетчера. Диспетчер, в свою очередь, сообщает всем магазинам о только что выполненном действии, и магазины обновляются сами. Магазин в Flux соответствует (общей) модели в MVVM. это не обычай для какого-либо конкретного представления. Поэтому обычно, когда люди используют React и Flux, каждый компонент React фактически реализует шаблон MVVM. Когда происходит действие, модель представления вызывает диспетчера, и, наконец, она обновляется в соответствии с изменениями в хранилище, которым является модель. Нельзя сказать, что каждый компонент реализует MVC, потому что в MVC только контроллер может обновлять модель представления.

mvc на стороне сервера и mvvm на стороне клиента (браузер) в веб-разработке.

Большую часть времени JavaScript используется в браузере для mvvm. Есть много серверных технологий для MVC.

Короче говоря, в MVC Controler осведомлен о представлении (элементах управления), а в MVVM ViewModel не знает, кто его использует. ViewModel предоставляет свои наблюдаемые свойства и действия тому, кто может быть заинтересован в его использовании. Этот факт облегчает тестирование, поскольку в ViewModel нет ссылки на пользовательский интерфейс.

Модель – Вид – Контроллер (обычно известный как MVC ) - это шаблон проектирования программного обеспечения, который обычно используется для разработки пользовательских интерфейсов, которые разделяют логику соответствующей программы на три взаимосвязанных элемента. Это делается для отделения внутренних представлений информации от способов представления и принятия информации пользователем. Следуя архитектурному шаблону MVC, эти основные компоненты разделяются, что позволяет повторно использовать код и выполнять параллельную разработку.

Традиционно используемый для настольных графических пользовательских интерфейсов (GUI), этот шаблон стал популярным для разработки веб-приложений. Популярные языки программирования, такие как JavaScript, Python, Ruby, PHP, Java и C #, имеют MVC-фреймворки, которые используются при разработке веб-приложений.

модель

Центральный компонент узора. Это динамическая структура данных приложения, независимая от пользовательского интерфейса. Он напрямую управляет данными, логикой и правилами приложения.

Посмотреть

Любое представление информации, такой как диаграмма, диаграмма или таблица. Возможно несколько представлений одной и той же информации, например, гистограмма для управления и табличное представление для бухгалтеров.

контроллер

Принимает ввод и преобразует его в команды для модели или вида.

В дополнение к разделению приложения на эти компоненты, модель модель-представление-контроллер определяет взаимодействия между ними.

Модель отвечает за управление данными приложения. Он получает пользовательский ввод от контроллера.

Представление означает представление модели в определенном формате.

Контроллер отвечает на пользовательский ввод и выполняет взаимодействия с объектами модели данных. Контроллер получает ввод, опционально проверяет его и затем передает ввод в модель.

Model – View – ViewModel (MVVM) - это программный архитектурный паттерн.

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

MVVM - это вариация шаблона проектирования модели презентации Мартина Фаулера. MVVM абстрагирует состояние и поведение представления таким же образом, но модель представления абстрагирует представление (создает модель представления) способом, не зависящим от конкретной платформы пользовательского интерфейса.

MVVM был изобретен архитекторами Microsoft Кеном Купером и Тедом Питерсом специально для упрощения событийного программирования пользовательских интерфейсов. Шаблон был включен в Windows Presentation Foundation (WPF) (графическая система Microsoft .NET) и Silverlight (производное интернет-приложения WPF). Джон Госсман, один из архитекторов Microsoft WPF и Silverlight, объявил о MVVM в своем блоге в 2005 году.

Модель – Вид – ViewModel также называется моделью – вид – связыватель, особенно в реализациях, в которых не используется платформа .NET. ZK (платформа веб-приложений, написанная на Java) и KnockoutJS (библиотека JavaScript) используют модель – представление – связующее.