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

Существует ли разница между стандартным шаблоном "Model View Controller" и шаблоном модели Microsoft Model/View/ViewModel?

1154
20 марта '09 в 23:09
источник поделиться
22 ответов

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:

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

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

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

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

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

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

600
22 авг. '10 в 12:19
источник

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

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

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

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

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

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

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

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

222
13 февр. '13 в 17:11
источник

MVVM Model-View ViewModel похож на MVC, Контроллер Model-View

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

Russel East обсуждает более подробно блог Почему MVVM отличается от MVC

167
20 марта '09 в 23:18
источник

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

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

86
20 марта '09 в 23:17
источник

Вы можете увидеть объяснение шаблона MVVM в среде Windows:

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

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

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

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

45
12 июня '13 в 23:48
источник

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

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

39
21 мая '10 в 14:38
источник

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

введите описание изображения здесь

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

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

MVVM (модель просмотра вида модели)

ViewModel

  • Это представление состояния представления.
  • Он содержит данные, отображаемые в представлении.
  • Отвечает на просмотр событий, например, логики представления.
  • Вызывает другие функции для обработки бизнес-логики.
  • Никогда напрямую не запрашивает представление для отображения.
17
14 дек. '16 в 3:20
источник

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

17
28 марта '09 в 0:22
источник

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

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

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

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

13
23 марта '10 в 13:16
источник

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

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

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

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

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

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

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

Итак... что нужно помнить, чтобы понять это правильно. Решите перед началом проектирования вашего приложения и STICK TO IT.

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

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

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

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

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

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

11
25 янв. '17 в 8:15
источник

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

  • Контроллер отвечает за создание ViewModel и ввод его в представление. (для получения запросов)
  • ViewModel - это контейнер для DataContext и состояние просмотра, такое как последний выбранный элемент и т.д.
  • Модель содержит объекты DB и очень близко к схеме БД, она выполняет запросы и фильтрацию. (Мне нравится EF и LINQ для этого)
  • Модель также должна учитывать репозитории и/или результаты результатов в сильные типы (EF имеет отличный метод... EF.Database.Select(querystring, parms) для прямого доступа к ADO для запроса запросов и возврата сильных типов. адреса EF - это медленный аргумент. EF НЕ МЕДЛЕННО!
  • ViewModel получает данные и выполняет бизнес-правила и проверку
  • Контроллер в post back будет обрабатывать метод ViewModel Post и ждать результатов.
  • Контроллер будет вводить обновленную Viewmodel в представление. В представлении используется привязка только сильного типа.
  • Вид просто отображает данные и отправляет события обратно контроллеру. (см. примеры ниже).
  • MVC перехватывает входящий запрос и перенаправляет его на правильный контроллер с сильным типом данных

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

В разъяснении пункта 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 в действии.

8
15 окт. '14 в 16:58
источник

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

8
22 авг. '10 в 10:42
источник

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

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

8
20 марта '09 в 23:20
источник

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

7
26 авг. '14 в 9:23
источник

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

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

6
28 сент. '13 в 12:10
источник

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

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

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

4
09 окт. '10 в 9:17
источник

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

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

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

Взгляд: что это? [ MVVM | MVP | MVC ]

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

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

(Просмотр вызова ViewModel | Presenter | Controller...) [ MVVM | MVP | MVC ]

View: Hey ViewModel | Presenter | Controller, Пользователь только что нажал кнопку поиска, что мне делать? [ MVVM | MVP | MVC ]

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

Вид: Да,... вот он... "фортепиано" [ MVVM | MVP | MVC ]

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

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

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

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

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

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

ViewModel | Presenter | Контроллер: Hey Model, У вас есть к этому поисковому запросу??: "piano" [ MVVM | MVP | MVC ]

Модель: Hey ViewModel | Presenter | Контроллер, позвольте мне проверить... [ MVVM | MVP | MVC ]

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

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

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

Модель: я нашел для вас список, ViewModel | Presenter, вот он в JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}] "[ MVVM | MVP ]

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

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

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

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

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

Взгляд: Большое спасибо Presenter [ MVP ]

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

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

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

3
19 мая '18 в 9:19
источник

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

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

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

3
24 июня '18 в 0:38
источник

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

2
17 дек. '14 в 20:53
источник

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

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

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

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

2
08 нояб. '16 в 4:09
источник

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

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

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

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

2
02 марта '17 в 13:38
источник

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

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

1
03 янв. '18 в 12:49
источник

Посмотрите другие вопросы по меткам или Задайте вопрос