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

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

20.03.2009 20:09:18
Обратите внимание, что хотя MVVM был придуман Microsoft, многие разработчики и проекты сторонних разработчиков начали применять этот шаблон. Этот комментарий был передан вам отделом злобных ненавистников.
BoltClock♦ 8.10.2013 05:10:16
После долгой работы с MVVM моя первая кисть с MVC была разочаровывающей, пока я не узнал, что могу передавать ViewModels назад и вперед в браузер, используя методы привязки, найденные в MVVM. Но, как сказал Джоэл выше, единственный способ вернуть состояние из браузера - это опубликовать изменения в форме (которая использует имя / значение) пары. Если вы не очень хорошо понимаете это. Вам будет трудно в MVC. Просто посмотрите на контроллер как на инжектор зависимостей для представления, и все готово.
John Peters 15.10.2014 13:27:50
Такой поднятый вопрос о высоком уровне [шаблонах проектирования]. Я хотел бы предложить использование диаграмм в ответах.
Ricardo 10.02.2015 18:33:52
Вот архивированная версия статьи Джоэла: web.archive.org/web/20150219153055/http://joel.inpointform.net/…
Tereza Tomcova 7.07.2017 13:26:59
В отличие от метода MVC, ViewModel не является контроллером. Вместо этого он действует как связующий элемент, который связывает данные между представлением и моделью. Принимая во внимание, что формат MVC специально разработан, чтобы создать разделение проблем между моделью и представлением, формат MVVM с привязкой данных разработан специально, чтобы позволить представлению и модели напрямую взаимодействовать друг с другом. hackernoon.com/…
blueray 6.12.2017 12:20:57
25 ОТВЕТОВ
РЕШЕНИЕ

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.

678
20.03.2019 10:09:34
@ Томаш Зелински: Да, но «где они используются» - это не вопрос (или смысл моего ответа). Я хочу сказать, что контроллеры все еще полезны в MVVM.
Gone Coding 14.07.2011 07:43:12
Согласен. Мой комментарий был вызван внезапным оживлением, а не потому, что я не согласен с вами.
Tomasz Zieliński 14.07.2011 14:57:44
Мы также использовали контроллеры для управления «потоком» представлений в подобном мастеру пользовательском интерфейсе.
riezebosch 15.08.2012 14:28:40
@Justin: я вижу, что моя формулировка этого предложения немного двусмысленна. Я на самом деле имею в виду, что модульное тестирование для всех компонентов легче поддерживать, а не просто улучшать тестирование ViewModels (что, как вы указываете, на самом деле не делает так много в MVCVM ... что вам нужно). Реальное преимущество контроллеров заключается в том, что вы фактически удаляете большинство требований для тестирования из ViewModel (где люди продолжают толкать логику контроллера) и помещаете его туда, где его можно тестировать (главным образом, контроллеры и модели). Комментарий повторного использования относится к виртуальным машинам в этом предложении. Я отредактировал это.
Gone Coding 12.06.2013 09:37:36
@TomaszZielinski M (MVVM) C
Mohamed Emad 17.11.2014 12:08:41

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

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

91
13.02.2012 20:11:51
Я думаю, что абзац, который вы цитировали, подытоживает это ИМХО Аспект ViewModel заключается в том, что это упрощенная / измененная версия модели для вида. Многие другие модели MV * связаны с реальной моделью.
Daniel Auger 20.03.2009 21:33:58
«Многие другие шаблоны MV * снова связывают реальную модель»? Правда? Я думал, что представление всегда должно было привязываться к контроллеру в MVC, несмотря ни на что.
PlagueHammer 9.04.2011 15:31:11
Ноктюрн: В классическом MVC View не имеет ничего общего с контроллером, он в основном привязан к Model. Думайте об этом как о роботе - модель представляет положение суставов робота, вид - это ЖК-монитор, на котором вы видите робота, контроллер - например, клавиатура. При такой настройке вид зависит от модели, то есть пространственное положение робота, которое вы видите на мониторе, является прямым представлением модели.
Tomasz Zieliński 13.07.2011 22:55:11
@Nocturne То, что Даниэль сказал, что, хотя официально все MV * должны использовать отдельную виртуальную машину, многие разработчики просто игнорируют ее и передают фактическую модель, и фактически ничего в спецификациях, например, для MVC, не запрещает ее, однако в MVVM одно должна ли ВМ быть ответственной за переход между моделью и представлением
yoel halb 27.07.2014 06:34:09
Я бы сказал так: модель - вещь, близкая к схеме БД. Когда выполняется запрос, он может проецировать данные в строгие типы на уровне модели. Модель представления - это совокупность объектов, включая объекты модели, но она может сохранять состояние представления относительно данных. Контроллер - просто гаишник между моделью представления и представлением, и, конечно, представление касается только состояний представления.
John Peters 15.10.2014 13:40:20

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

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

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

175
1.02.2017 16:24:36
Предложение «Контроллер заменен моделью представления» неверно. В MVVM роль контроллера заключается в связывании данных (или связывании по соглашению, если вы его используете).
DaniCE 23.03.2010 09:58:25
MVVM будет иметь смысл только при использовании двусторонней привязки данных WPF. В противном случае MVC / MVP и т. Д. Будет достаточно.
Jeff 20.09.2010 23:42:39
@DaniCE: Джош Смит:If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. …
sll 13.02.2012 20:30:50
@OmShankar 11-й не от вас. Всего 10 человек и 12 мнений. Под поговоркой подразумевается, что определения этих шаблонов настолько открыты для интерпретации, что, по крайней мере, два человека будут достаточно смущены, чтобы иметь более одного мнения.
Dan Bechard 9.05.2014 13:52:29
@DaniCE Ну, это на самом деле точка привязки данных WPF, и Microsoft изобрела MVVM, в которой можно полностью обойти контроллер (утверждая, что предложение «Контроллер заменяется моделью представления» неверно только потому, что существует контроллер за кулисами - это все равно, что утверждать, что утверждение «язык более высокого уровня заменяет использование зашифрованного машинного кода более читаемым» неверно, потому что за кулисами машинный язык все еще используется ...)
yoel halb 27.07.2014 06:17:31

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

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

9
20.03.2009 20:20:58
Строго говоря, MVVM - это модель представления, хотя MVVM становится предпочтительным именем для конкретной реализации шаблона в WPF.
wekempf 27.03.2009 21:26:16
Согласовано. Viewmodel в MVC "IS" конечный автомат для представления. Он содержит текстовый текст данных и отслеживает всю информацию выбранного элемента, а также может содержать всю логику проверки с использованием интерфейса IValidatableObject. ViewModel взаимодействует с БД на уровне модели, которая может использовать строго типизированные модели. MVVM в WPF является контроллером MVC. Но контроллер MVC намного чище, он необходим обработчику маршрутизации.
John Peters 15.10.2014 13:51:48

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

18
27.03.2009 21:22:48
В 2009 году этот ответ был, вероятно, хорошим, но сегодня нет споров, так как даже элементы управления HTML Helper из MSFT позволяют связывать с помощью печально известных помощников «For». Нокаут это все о привязке данных на стороне клиента.
John Peters 15.10.2014 13:47:48
Я заявил об этом в 2009 году, потому что слишком много людей в сообществе приняли этот ответ. Я сказал , что это спорно, потому что MVVM и представление модели на самом деле тот же шаблон под разными именами. Вопреки популярности в WPF, сегодня это часто называют MVVM в других средах, но любое имя является точным.
wekempf 26.07.2017 20:16:34

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

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

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

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

15
28.07.2014 08:08:46

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

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

45
28.02.2012 18:52:29
+1. Термин правильный, я думаю. а о создании гибридного M-MProxy-VC не так уж много разделения? я думаю, что было бы достаточно использовать MVC, тогда как M - это модель с полной поддержкой Binding. ;)
ktutnik 24.08.2010 13:14:02
+1. Как я уже говорил выше, я думаю, что MVC используется для разработки целого (веб) приложения, в то время как MVVM используется внутри компонента View MVC.
Tomasz Zieliński 13.07.2011 23:01:38
@ktutnik: Модель обычно находится на сервере, тогда как ViewModel живет на клиенте. Поэтому HTML не имеет возможности напрямую связываться с моделью на стороне сервера. Поэтому нам нужен ModelView, который действует как локальный несохраненный рабочий набор данных, извлеченных из модели с использованием, например, AJAX / JSON.
Tomasz Zieliński 13.07.2011 23:03:41
Представление действительно «читает» данные модели, потому что они уже были помещены туда контроллером. Мне нравится называть это «вводом данных» контроллером, поскольку именно контроллер отвечает. Весь взгляд делает в рендере и запускает события в моей голове.
John Peters 15.10.2014 13:46:13
Я извиняюсь, но не согласен с интерпретацией MVVM. ViewModel не имеет представления о представлении, о том, как будет выглядеть представление или как он будет реагировать, а модель также не имеет представления о модели представления. Фактически, View также не должен даже знать о Model, просто ViewModel. Модель должна представлять данные и состояние приложения, ViewModel должен преобразовывать состояние в данные с поддержкой пользовательского интерфейса (я рекомендую все примитивы на этом этапе), а View должен реагировать на перевод ViewModels. Данные часто будут одинаковыми, но они все равно должны быть упакованы и повторно доставлены через ViewModel, и никаких контроллеров не существует.
Michael Puckett II 25.01.2017 05:25:49

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

9
22.08.2010 07:42:43
ИМХО я бы сказал , что «делает контроллеры более многоразовый» является слишком широким заявлением и контрпродуктивно для общих «контролеров» ASP.Net (т.е. не бизнес - логики) , поскольку эти контроллеры , как правило , содержат части приложения, которые APPLICATION- конкретный . Это представления, модели, ViewModels и бизнес-логика, которые необходимо использовать повторно. Я бы подумал, что лучше рассматривать модули бизнес-логики как поставщиков услуг, а не как контроллеров.
Gone Coding 29.04.2015 08:52:45
Но вы говорите о «ViewModel» в Asp.net, а не о шаблоне проектирования MVVM. Две разные вещи.
Luis 27.04.2018 16:26:22

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

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

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

4
9.10.2010 06:17:24

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

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

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

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

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

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

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

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

 

271
18.02.2020 14:12:42
MVC не возникла в Интернете. Trygve Reenskaug ввел MVC в Smalltalk-76 в 1970-х.
Arialdo Martini 2.05.2014 21:02:28
Даже если это было изменено на «MVC был популяризирован через дизайн веб-приложений». Я бы сказал, что это спекуляция без надлежащего цитирования.
Dan Bechard 9.05.2014 13:58:08
Arialdo: Спасибо, я не знал о Smalltalk-76. (Играли тогда с другими игрушками. :) Шутки в сторону, интересно, сколько лет некоторым из этих концепций. @Dan, то, что я написал, это: «[MVC], возможно, был там раньше [в Интернете], но Интернет - это то, как он получил популярность в массы веб-разработчиков». Я все еще думаю, что это правильно. У меня нет на это цитаты, но тогда я не чувствую, что мне это нужно, потому что массовая популяризация MVC является частью моего личного опыта, когда я начинал как веб-разработчик в начале прошлого десятилетия. Apache Struts был в моде тогда, с большим количеством компонентов для MVC.
Lumi 10.05.2014 07:48:34
MVC не является «по существу односторонней связью», так как браузеры постоянно выдают Gets и Posts. И Gets, и Posts могут изменять значения полей, найденные в строке запроса. Это дает браузерам широкие возможности для отправки информации обратно на контроллер. MVC был построен поверх HTTP 1.0, который всегда имел в виду двустороннюю связь.
John Peters 15.10.2014 13:43:31
Спасибо, Луми. Это имело для меня гораздо больше смысла, чем другие ответы. Это правильно? Не имею представления. Но с моей точки зрения это было по крайней мере связным.
gcdev 24.06.2015 14:01:44

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

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

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

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

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

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

52
13.08.2019 17:13:08
Обратите внимание, что хотя упомянутая статья относится к разработке с использованием Microsoft Stack, в частности Windows Phone, и XAML, это не обязательно.
Richard Nalezynski 8.11.2016 00:47:03
Этот ответ выдвигает на первый план проблему с названием "MVVM" - это должно быть "VVMM" или "MVMV" - MV-VM имеет совершенно неправильные отношения!
Etherman 25.03.2019 08:43:01

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

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

6
28.09.2013 09:35:20
То, что «веб-разработка» называет «MVC», является не чем иным, как разделением интересов, а не подлинным MVC, который предшествовал сети.
Terrence Brannon 10.11.2016 17:09:49

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

9
26.08.2014 06:23:32
Ого ... так и MVC, и MVVM пришли с SmallTalk ?? Они явно опередили свое время, очевидно ...
MattE 19.10.2016 04:22:17
На самом деле, говорить, что это произошло от модели представления Мартина Фаулера, не совсем точно. Очень сложно определить, что появилось первым, но оба шаблона (если учесть, что это действительно один и тот же шаблон) были получены независимо и примерно в одно и то же время.
wekempf 26.07.2017 20:13:28

Внедрение строго типизированных моделей представления в представление с использованием 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 в действии.

10
31.05.2017 16:04:16
Можете ли вы уточнить пункт 6? Я понимаю, что вы рассматриваете только ASP.Net, но, похоже, он добавляет нежелательную зависимость к ViewModel. (например, знание того, откуда данные поступают / отправляются). Пример кода (псевдокода?) Был бы полезен для пояснения этого ответа и показа, какие части находятся на стороне сервера, а какие - на стороне клиента.
Gone Coding 29.04.2015 08:46:49

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

2
19.12.2014 20:17:54

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

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

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

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

2
23.05.2017 10:31:39

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

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

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

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

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

ViewModel :

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

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. просто переведите состояние модели. Таким образом, представление является полностью реактивным и общим и может использоваться во многих различных ситуациях.

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

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

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

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

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

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

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

23
1.06.2019 20:15:51
Удивительно подробный и точный ответ! Сделал это кристально чистым для меня. :-)
ankush981 15.12.2018 07:26:13
«изучение этого может быть очень запутанным, поскольку вы найдете много плохой информации в сети». Ага. Как человек, который, кажется, имеет большой опыт работы с этими шаблонами проектирования, знаете ли вы какие-нибудь хорошие учебники / руководства?
MarredCheese 15.03.2019 19:53:13
Честно говоря, мои знания MVVM были получены годами или методом проб и ошибок, и я использовал / делал это различными способами, основываясь на командных усилиях. Недавно (2 года назад) я смог применить свой собственный опыт в обобщенном плане игры и привести команду к тому, чтобы закончить, и мы были чрезвычайно успешны. Тем не менее, я не могу указать вам в одном месте и извиниться. Я могу сказать, что вы правы, из-за различных мнений это очень запутанно, но, IMO, с MVVM это должно быть как можно более общим. Сделайте ViewModels способными разрешать представлениям строго связываться и работать с данными, но для ЛЮБОГО представления ...
Michael Puckett II 18.03.2019 19:38:59
Другими словами, НИКОГДА не заставляйте ViewModel предполагать, что View будет выглядеть или действовать каким-либо образом. Для меня ViewModel лучше всего использовать как API, но со строгой связью. Следуйте плану игры для привязки, редактирования, командования и т. Д. Если представлению требуется дополнительная логика для функционирования определенным образом, который не имеет ничего общего с приложением или данными (такими как анимация или раскрывающийся список ...), тогда эта логика принадлежит где-то к уровню просмотра. Опять же, существует множество мнений, и это только мое, но у меня здесь сильный опыт и солидный послужной список.
Michael Puckett II 18.03.2019 19:42:38
У меня есть примеры приложений, которыми я не против поделиться, или я не против устроить простое шоу и рассказать вам или кому-либо еще, если вы хотите или любопытно.
Michael Puckett II 18.03.2019 19:44:46

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

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

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

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

2
11.09.2017 16:00:22

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

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

2
3.01.2018 09:49:40

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

Пытаясь пролить свет на вышесказанное, я составил этот сценарий с участием 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 ]

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

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

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

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

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

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

12
19.05.2018 06:19:42
Здесь есть отличный ответ на весь текст аромата ... С некоторым форматированием и небольшим разговором между компонентами это может быть лучшим на этой странице.
neonblitzer 13.03.2020 21:00:01

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

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

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

4
25.06.2018 11:19:46

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

1
30.06.2019 19:01:04

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

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 проще для новых разработчиков.
3
5.04.2020 20:25:02
Лучшее объяснение
p32094 23.03.2020 05:13:50

Модель – Вид – Контроллер (обычно известный как 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) используют модель – представление – связующее. введите описание изображения здесь

1
5.12.2019 13:07:51