В чем разница между MVC и MVVM?

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

первая аббревиатура, MVC, возникла в интернете. (Да, возможно, это было раньше, но интернет-это то, как он популяризировался среди масс веб-разработчиков.) Подумайте о базе данных, HTML-страницах и коде промежуточный. Давайте немного уточним это, чтобы прийти к MVC: для "базы данных" предположим, что код интерфейса database plus. Для" HTML-страниц " предположим, что HTML-шаблоны плюс код обработки шаблонов. Для" code inbetween " предположим, что пользователь сопоставления кода нажимает на действия, возможно, влияющие на базу данных, определенно вызывая другое представление. Вот и все, по крайней мере для сравнения.

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

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

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

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

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

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

MVVM Модель-Вид ViewModel похоже на MVC,Model-View Controller

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

Рассел Востоке делает блог, обсуждающий более подробно почему MVVM отличается от MVC

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

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

вы можете см. объяснение шаблона 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 предоставляет всю функциональность.

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

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

MVC (Модель-Представление-Контроллер)

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

MVVM (Вид Модели Вид Модели)

ViewModel:

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

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

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

шаблон MVVM-это просто обобщение эта практика для всех элементов UI.

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

MVC-это управляемая среда, а MVVM-реактивная среда.

в контролируемой среде у вас должно быть меньше кода и общий источник логики; который всегда должен жить в контроллере. Однако; в веб-мире MVC легко делится на логику создания представления и динамическую логику представления. Создание живет на сервере, а динамическое - на клиенте. Вы видите это много с ASP.NET MVC в сочетании с AngularJS, тогда как сервер будет создавать просмотр и передача модели и отправка ее клиенту. Затем клиент будет взаимодействовать с представлением, и в этом случае AngularJS выполняет шаги в качестве локального контроллера. После отправки модель или новая модель передается обратно контроллеру сервера и обрабатывается. (Таким образом, цикл продолжается, и есть много других переводов этой обработки при работе с сокетами или AJAX и т. д., Но по всей архитектуре идентичен.)

MVVM-это реактивная среда, означающая, что вы обычно пишете код (например, триггеры), который будет активироваться на основе некоторого события. В XAML, где MVVM процветает, все это легко сделать со встроенной платформой привязки данных, но, как уже упоминалось, это будет работать на любой системе в любом представлении с любым языком программирования. Это не ms конкретными. ViewModel срабатывает (обычно событие изменения свойства), и представление реагирует на него на основе любых триггеров, которые вы создаете. Это может получить технический, но суть в том, что вид без гражданства и без логики. Он просто меняется. состояние на основе значений. Кроме того, ViewModels являются апатридами с очень малой логикой, а модели-это состояние С по существу нулевой логикой, поскольку они должны поддерживать только состояние. Я описываю это как состояние приложения (модель), переводчик состояния (ViewModel), а затем визуальное состояние / взаимодействие (представление).

в настольном или клиентском приложении MVC у вас должна быть модель, и модель должна использоваться контроллером. На основе модели контроллер изменит вид. Просмотр обычно привязаны к контроллерам с интерфейсами, так что контроллер может работать с различными представлениями. В ASP.NET логика для MVC немного назад на сервере, поскольку контроллер управляет моделями и передает модели в выбранное представление. Затем представление заполняется данными на основе модели и имеет собственную логику (обычно другой набор MVC, например, с AngularJS). Люди будут спорить и путать это с приложением MVC и пытаться сделать как в этот момент, поддерживая проект со временем превратится в катастрофу. Всегда ставьте логику и управление в одном месте при использовании MVC. Не записывайте логику представления в код позади представления (или в представлении через JS для интернета) для размещения данных контроллера или модели. Пусть контроллер изменит представление. Единственная логика, которая должна жить в представлении, - это все, что требуется для создания и запуска через интерфейс, который он использует. Примером этого является отправка имени пользователя и пароля. Будь то рабочий стол или веб-страница (на клиенте) Контроллер должен обрабатывать процесс отправки всякий раз, когда представление запускает действие отправки. Если все сделано правильно, вы всегда можете легко найти свой путь вокруг веб-приложения MVC или локального приложения.

MVVM лично мой любимый, поскольку он полностью реактивный. Если модель изменяет состояние, ViewModel слушает и переводит это состояние, и все!!! Затем представление прослушивает ViewModel для изменения состояния, а также обновляется на основе перевода из ViewModel. Некоторые называют его чистым. MVVM, но на самом деле есть только один, и мне все равно, как вы его аргументируете, и это всегда чистый MVVM, где представление не содержит абсолютно никакой логики.

вот небольшой пример:Предположим, вы хотите, чтобы меню скользило по нажатию кнопки. В MVC у вас будет MenuPressed действие в вашем интерфейсе. Контроллер будет знать, когда вы нажмете кнопку Меню, а затем скажите виду скользить в меню на основе другого метода интерфейса, такого как SlideMenuIn. Зачем туда и обратно? Если контроллер решит, что вы не можете или хотите сделать что-то еще, вот почему. Контроллер должен отвечать за представление, а представление ничего не делает, если контроллер этого не говорит. Однако; в MVVM меню слайдов в анимации должно быть встроено и общее, и вместо того, чтобы говорить, чтобы скользить, это будет сделано на основе некоторого значения. Поэтому он слушает ViewModel, и когда ViewModel говорит, IsMenuActive = true (или, тем не менее) анимация для этого происходит. Теперь, с этим сказано Я хочу прояснить еще один момент и, пожалуйста, обратите внимание. IsMenuActive, вероятно, плохой дизайн MVVM или ViewModel. При разработке ViewModel вы никогда не должны предполагать, что представление будет иметь какие-либо функции вообще и просто передать переведенное состояние модели. Таким образом, если вы решите изменить свой вид, чтобы удалить меню и просто показать данные / параметры другим способом, ViewModel не волнует. Так как бы Вы управляли меню? Когда данные имеют смысл, вот как. Итак, один из способов сделать это-дать в меню список опций (возможно, массив внутренних ViewModels). Если в этом списке есть данные, меню знает, что открывается через триггер, если нет, то он знает, что скрывается через триггер. У вас просто есть данные для меню или нет в ViewModel. Не решайте показывать / скрывать эти данные в ViewModel.. просто переведите состояние модели. Таким образом, представление является полностью реактивным и общим и может использоваться во многих различных ситуациях.

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

Так... вещи, которые нужно иметь в виду, чтобы сделать это правильно. Решите заранее, как разработать приложение и придерживаться его.

Если вы делаете MVC, что здорово, то убедитесь, что контроллер управляемый и полностью контролирует ваш вид. Если у вас большое представление, подумайте о добавлении элементов управления к представлению, которое имеет разные контроллеры. Просто не каскадируйте эти контроллеры на разные контроллеры. Очень неприятно поддерживать. Найдите момент и спроектируйте вещи отдельно таким образом, чтобы они работали как отдельные компоненты... И всегда позволяйте контроллеру сообщать модели о фиксации или сохранении хранилища. Идеальная настройка зависимостей для MVC in - Просмотр Controller Контроллер → Модель или с ASP.NET (не заводи меня) Model Controller View Controller Controller → Model (где модель может быть та же или совершенно другая модель от контроллера для просмотра) ...конечно, единственное, что нужно знать о контроллере на данный момент, - это в основном для ссылки на конечную точку, чтобы знать, где передать модель.

Если вы делаете MVVM, я благословляю вашу добрую душу, но найдите время, чтобы сделать это правильно! Не используйте интерфейсы для одного. Пусть Ваше мнение решает, как оно будет выглядеть на основе ценностей. Играть с видом с макет данных. Если вы хотите посмотреть, что показывает вам меню (по пример), хотя вы не хотели этого в то время, тогда хорошо. Ваше представление работает так, как должно, и реагирует на основе значений так, как должно. Просто добавьте еще несколько требований к триггеру, чтобы убедиться, что это не происходит, когда ViewModel находится в определенном переведенном состоянии или команда ViewModel очистить это состояние. В вашей ViewModel не удаляйте это с внутренней логикой, как будто вы решаете оттуда, должно ли представление видеть это. Помни, ты не можешь предполагать. есть меню или нет в ViewModel. И, наконец, модель должна просто позволить вам изменить и, скорее всего, сохранить состояние. Здесь произойдет проверка и все остальное; например, если модель не может изменить состояние, она просто помечает себя как грязную или что-то еще. Когда ViewModel поймет это, он переведет, что грязно, и представление поймет это и покажет некоторую информацию через другой триггер. Все данные в представлении могут быть привязаны к ViewModel, поэтому все может быть динамическая только модель и ViewModel абсолютно не имеют представления о том, как представление будет реагировать на привязку. На самом деле модель также не имеет представления о ViewModel. При настройке зависимостей они должны указывать так и только так Вид → ViewModel → Модель (и примечания здесь... и это, вероятно, тоже будет обсуждаться, но мне все равно... Не передавайте модель в представление. В представлении не должен отображаться период модели. Я даю крысам трещину, что вы видели или как ты это сделал, это неправильно.)

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

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

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

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

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

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

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

ввод строго типизированных ViewModels в представление с помощью MVC

1. контроллер отвечает за создание ViewModel и введение его в представление. (для GET-запросов)
2. ViewModel-это контейнер для состояния DataContext и view, такого как последний выбранный элемент и т. д.
3. модель содержит объекты БД и очень близка к схеме БД, она выполняет запросы и фильтрацию. (Мне нравится EF и LINQ для этого)
4. модель должна также рассмотрим репозитории и / или проекцию результатов на сильные типы (EF имеет отличный метод... ФВ.База данных.Выберите (querystring, parms) для прямого доступа ADO для ввода запросов и возврата сильных типов. Это адресует EF медленный аргумент. EF не медленный!
5. ViewModel получает данные и выполняет бизнес-правила и проверку
6. контроллер ответ будет вызывать метод ViewModel Post и ждать результаты.
7. контроллер введет недавно обновленную Viewmodel в представление. В представлении используется только сильная привязка типа.
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!";
 }
}

метод контроллера post будет выглядеть следующим образом (см. ниже), обратите внимание, что экземпляр 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);
}

обратите внимание, что для того, чтобы этот actionmethod выше работал так, как вы намереваетесь, у вас должен быть определен нулевой CTOR, который intializes вещи, не возвращенные в post. Пост обратно, и обратно после пары имя/значение для тех вещей, которые изменились. Если отсутствуют пары имя / значение, механизм привязки MVC делает правильную вещь, которая просто ничего! Если это произойдет, вы можете сказать :"я теряю данные на post спины."..

преимущество этого шаблона-ViewModel делает всю работу "беспорядка", взаимодействующую с логикой модели/бизнеса, контроллер-это просто маршрутизатор. Это SOC в действии.

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

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

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

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

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

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

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

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

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

аналогично, a Современные клиентские рамки, такие как Угловое следует шаблону MVC по соглашению, но также добавляет службу. Интересно, что он рекламируется как Model-View-Whatever (MVW). (См.это сообщение о переполнении стека.)

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

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

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

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

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

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

пытаясь пролить свет на вышесказанное, я составил этот сценарий с участием MVVM, MVP и MVC. История начинается с нажатия пользователем кнопки "найти" в приложении поиска фильмов… :

Пользователей: Нажмите Кнопку ...

посмотреть: кто это? [MVVM|MVP / MVC]

пользователь: я просто нажал на кнопку поиска ...

посмотреть: хорошо, подождите секунду ... [MVVM|MVP / MVC]

( посмотреть вызов ViewModel|ведущий|контроллер ... ) [MVVM|MVP / MVC]

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

ViewModel|ведущий|контроллер: Привет посмотреть, есть ли какой-либо поисковый запрос на этой странице? [MVVM|MVP / MVC]

посмотреть: Да, ... вот оно ... "пианино" [MVVM|MVP / MVC]

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

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

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

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

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

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

ViewModel|ведущий|контроллер: Привет модель, ты хоть матч за этот срок поиска?: "фортепиано" [MVVM|MVP|MVC]

модель: Привет ViewModel|ведущий|контроллер, позвольте мне проверить … [MVVM|MVP|MVC]

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

( через некоторое время ... )

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

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

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

(ведущий|контроллер спасибо модель и вернется в посмотреть) [MVP|MVC]

ведущий: Спасибо за ожидание посмотреть, я нашел список совпадающих результатов для вас и расположил их в презентабельном формате: ["учитель фортепиано 2001","фортепиано 1993"]. Также, пожалуйста, скрыть индикатор выполнения сейчас [MVP]

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

ViewModel: любой наблюдатель на searchResultsListObservable будет уведомлен, что есть этот новый список в презентабельном формате: ["учитель фортепиано 2001","фортепиано 1993"].[MVVM]

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

посмотреть: спасибо "контроллер" [MVC] (ныне посмотреть ставит под сомнение себя: как я должен представить результаты, которые я получаю от модель пользователю? Должен ли год производства фильма Быть первым или последним...?)

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

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

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

MVVMC-правильное имя, на мой скромный взгляд.

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

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

большую часть времени javascript используется для mvvm в браузере. существует много серверных технологий для mvc.