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


1312

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


55
Обратите внимание, что хотя MVVM был придуман Microsoft, многие разработчики и проекты сторонних разработчиков начали применять этот шаблон. Этот комментарий был передан вам отделом злобных ненавистников.
BoltClock

1
После долгой работы с MVVM моя первая кисть с MVC была разочаровывающей, пока я не узнал, что могу передавать ViewModels назад и вперед в браузер, используя методы привязки, найденные в MVVM. Но, как сказал Джоэл выше, единственный способ вернуть состояние из браузера - это опубликовать изменения в форме (которая использует имя / значение) пары. Если вы не очень хорошо понимаете это. Вам будет трудно в MVC. Просто посмотрите на контроллер как на инжектор зависимостей для представления, и все готово.
Джон Питерс

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

4
Вот архивированная версия статьи Джоэла: web.archive.org/web/20150219153055/http://joel.inpointform.net/…
Тереза ​​Томцова,

1
В отличие от метода MVC, ViewModel не является контроллером. Вместо этого он действует как связующий элемент, который связывает данные между представлением и моделью. Принимая во внимание, что формат MVC специально разработан, чтобы создать разделение проблем между моделью и представлением, формат MVVM с привязкой данных разработан специально, чтобы позволить представлению и модели напрямую взаимодействовать друг с другом. hackernoon.com/…
blueray

Ответы:


684

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.


8
@ Томаш Зелински: Да, но «где они используются» - это не вопрос (или смысл моего ответа). Я хочу сказать, что контроллеры все еще полезны в MVVM.
Ушел кодирование

58
Согласен. Мой комментарий был вызван внезапным оживлением, а не потому, что я не согласен с вами.
Томаш Зелиньски

Мы также использовали контроллеры для управления «потоком» представлений в подобном мастеру пользовательском интерфейсе.
riezebosch

3
@Justin: я вижу, что моя формулировка этого предложения немного двусмысленна. Я на самом деле имею в виду, что модульное тестирование для всех компонентов легче поддерживать, а не просто улучшать тестирование ViewModels (что, как вы указываете, на самом деле не делает так много в MVCVM ... что вам нужно). Реальное преимущество контроллеров заключается в том, что вы фактически удаляете большинство требований для тестирования из ViewModel (где люди продолжают толкать логику контроллера) и помещаете его туда, где его можно тестировать (главным образом, контроллеры и модели). Комментарий для повторного использования относится к виртуальным машинам в этом предложении. Я отредактировал это.
Ушел кодирование

7
@TomaszZielinski M (MVVM) C
Мохамед Эмад

274

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

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

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

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

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

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

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

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

 


47
MVC не возникла в Интернете. Trygve Reenskaug ввел MVC в Smalltalk-76 в 1970-х годах.
Ариальдо Мартини

11
Даже если бы он был изменен на «MVC был популяризирован через дизайн веб-приложений». Я бы сказал, что это спекуляция без надлежащего цитирования.
Дэн Бешард

4
Arialdo: Спасибо, я не знал о Smalltalk-76. (Играли тогда с другими игрушками. :) Шутки в сторону, интересно, сколько лет некоторым из этих концепций. @Dan, то, что я написал, это: «[MVC], возможно, был там раньше [в Интернете], но Интернет - это то, как он стал популярен среди веб-разработчиков». Я все еще думаю, что это правильно. У меня нет на это цитаты, но тогда я не чувствую, что она мне нужна, потому что массовая популяризация MVC является частью моего личного опыта, когда я начинал как веб-разработчик в начале прошлого десятилетия. Apache Struts был тогда в моде, с большим количеством компонентов для MVC.
Луми

5
MVC не является «по существу односторонней связью», так как браузеры постоянно выдают Gets и Posts. И Gets, и Posts могут изменять значения полей, найденные в строке запроса. Это дает браузерам широкие возможности для отправки информации обратно на контроллер. MVC был построен на основе HTTP 1.0, который всегда имел в виду двустороннюю связь.
Джон Питерс

13
Спасибо, Луми. Это имело для меня гораздо больше смысла, чем другие ответы. Это правильно? Не имею представления. Но с моей точки зрения это было как минимум связно.
gcdev

175

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

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

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


81
Предложение «Контроллер заменен моделью представления» неверно. В MVVM роль контроллера заключается в связывании данных (или связывании по соглашению, если вы его используете).
DaniCE

9
MVVM будет иметь смысл только при использовании двусторонней привязки данных WPF. В противном случае MVC / MVP и т. Д. Будет достаточно.
Джефф

266
@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

7
@OmShankar 11-й не от вас. Всего 10 человек и 12 мнений. Поговорка подразумевает, что определения этих шаблонов настолько открыты для интерпретации, что, по крайней мере, два человека будут в замешательстве достаточно, чтобы иметь более одного мнения.
Дэн Бешард

7
@DaniCE Ну, это на самом деле точка привязки данных WPF, и Microsoft изобрела MVVM, в которой можно полностью обойти контроллер (утверждая, что предложение «Контроллер заменяется моделью представления» неверно только потому, что существует контроллер за кулисами - это все равно, что утверждать, что утверждение «язык более высокого уровня заменяет использование зашифрованного машинного кода более читаемым» неверно, потому что за кулисами машинный язык все еще используется ...)
Йоэль Хэлб

91

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

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


20
Я думаю, что параграф, который вы цитировали, подытоживает это, ИМХО. Аспект ViewModel заключается в том, что это упрощенная / измененная версия модели для вида. Многие другие шаблоны MV * связываются с реальной моделью.
Даниэль Ожер

1
«Многие другие шаблоны MV * снова связывают реальную модель»? Правда? Я думал, что представление всегда должно было привязываться к контроллеру в MVC, несмотря ни на что.
PlagueHammer

9
Ноктюрн: В классическом MVC View не имеет ничего общего с контроллером, он в основном привязан к Model. Думайте об этом как о роботе - модель представляет положение суставов робота, вид - это ЖК-монитор, на котором вы видите робота, контроллер - например, клавиатура. При такой настройке вид зависит от модели, то есть пространственное положение робота, которое вы видите на мониторе, является прямым представлением модели.
Томаш Зелиньски

@Nocturne То, что Даниэль сказал, что, хотя официально все MV * должны использовать отдельную ВМ, многие разработчики просто игнорируют ее и передают фактическую модель, и фактически ничего в спецификациях, например, для MVC, не запрещает ее, однако в MVVM одно должна ли ВМ быть ответственной за переход между моделью и представлением
Йоэл Хэлб

Я бы сказал так: модель - вещь, близкая к схеме БД. Когда запрос выполняется, он может проецировать данные в строгие типы на уровне модели. Модель представления - это совокупность вещей, включая объекты модели, но она может сохранять состояние представления относительно данных. Контроллер - просто гаишник между моделью представления и представлением, и конечно представление касается только состояний представления.
Джон Питерс

52

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

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

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

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

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

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


7
Обратите внимание, что хотя упомянутая статья относится к разработке с использованием Microsoft Stack, в частности Windows Phone, и XAML, это не обязательно.
Ричард Налезински

Этот ответ выдвигает на первый план проблему с именем «MVVM» - это должно быть «VVMM» или «MVMV» - MV-VM имеет совершенно неправильные отношения!
Etherman

45

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

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


1
+1. Термин правильный, я думаю. а о создании гибридного M-MProxy-VC не так уж много разделения? я думаю, что было бы достаточно использовать MVC, тогда как M - это модель с полной поддержкой Binding. ;)
ктутник

2
+1. Как я уже говорил выше, я думаю, что MVC используется для разработки всего (веб) приложения, в то время как MVVM используется внутри компонента View MVC.
Томаш Зелиньски

23
@ktutnik: модель обычно находится на сервере, тогда как ViewModel живет на клиенте. Поэтому HTML не имеет возможности напрямую связываться с моделью на стороне сервера. Поэтому нам нужен ModelView, который действует как локальный несохраненный рабочий набор данных, извлеченных из модели с использованием, например, AJAX / JSON.
Томаш Зелиньски

1
Представление действительно «читает» данные модели, потому что они уже были помещены туда контроллером. Мне нравится называть это «вводом данных» контроллером, поскольку именно контроллер отвечает. Весь взгляд делает в рендере и запускает события в моей голове.
Джон Питерс

3
Я извиняюсь, но не согласен с интерпретацией MVVM. ViewModel не имеет представления о представлении, о том, как будет выглядеть представление или как он будет реагировать, а модель также не имеет представления о модели представления. Фактически, View также не должен даже знать о Model, просто ViewModel. Модель должна представлять данные и состояние приложения, ViewModel должен преобразовывать состояние в данные с поддержкой пользовательского интерфейса (я рекомендую все примитивы на этом этапе), а View должен реагировать на перевод ViewModels. Данные часто будут одинаковыми, но они все равно должны быть упакованы и повторно доставлены через ViewModel, и никаких контроллеров не существует.
Майкл Пакетт II

24

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Удивительно подробный и точный ответ! Сделал это кристально чистым для меня. :-)
ankush981

«изучение этого может быть очень запутанным, поскольку вы найдете много плохой информации в сети». Ага. Как человек, который, кажется, имеет большой опыт работы с этими шаблонами проектирования, знаете ли вы какие-нибудь хорошие учебники / руководства?
MarredCheese

1
Честно говоря, мои знания MVVM были получены годами или методом проб и ошибок, и я использовал / делал это различными способами, основываясь на командных усилиях. Недавно (2 года назад) я смог применить свой собственный опыт в обобщенном плане игры и привести команду к тому, чтобы закончить, и мы были чрезвычайно успешны. Тем не менее, я не могу указать вам в одном месте и извиниться. Я могу сказать, что вы правы, из-за различных мнений это очень запутанно, но, IMO, с MVVM это должно быть как можно более общим. Сделайте ViewModels способными разрешать представлениям строго связываться и работать с данными, но для ЛЮБОГО представления ...
Michael Puckett II

1
Другими словами, НИКОГДА не заставляйте ViewModel предполагать, что View будет выглядеть или действовать каким-либо образом. Для меня ViewModel лучше всего использовать как API, но со строгой связью. Следуйте плану игры для привязки, редактирования, командования и т. Д. Если представлению требуется дополнительная логика для функционирования определенным образом, который не имеет ничего общего с приложением или данными (такими как анимация или раскрывающийся список ...), тогда эта логика принадлежит где-то к уровню просмотра. Опять же, существует множество мнений, и это только мое, но у меня здесь сильный опыт и солидный послужной список.
Майкл Пакетт II

У меня есть примеры приложений, которыми я не против поделиться, или я не против устроить простое шоу и рассказать вам или кому-либо еще, если вы хотите или любопытно.
Майкл Пакетт II

23

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

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

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

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

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

ViewModel :

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

18

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


1
В 2009 году этот ответ был, вероятно, хорошим, но сегодня нет споров, поскольку даже элементы управления HTML Helper из MSFT позволяют связывать с помощью печально известных помощников «For». Нокаут это все о привязке данных на стороне клиента.
Джон Питерс

1
Я заявил об этом в 2009 году, потому что слишком много людей в сообществе приняли этот ответ. Я сказал , что это спорно, потому что MVVM и представление модели на самом деле тот же шаблон под разными именами. Слава популярности в WPF, сегодня это часто называют MVVM в других средах, но любое имя является точным.
wekempf

15

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

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

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

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


13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Здесь есть отличный ответ на весь текст аромата ... С некоторым форматированием и небольшим разговором между компонентами это может быть лучшим на этой странице.
неонблицер

10

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


Можете ли вы уточнить пункт 6? Я понимаю, что вы рассматриваете только ASP.Net, но, похоже, он добавляет нежелательную зависимость к ViewModel. (например, знание того, откуда данные поступают / отправляются). Пример кода (псевдокода?) Был бы полезен для пояснения этого ответа и показа, какие части находятся на стороне сервера, а какие - на стороне клиента.
Ушел кодирование

9

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

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


3
Строго говоря, MVVM - это модель представления, хотя MVVM становится предпочтительным именем для конкретной реализации шаблона в WPF.
wekempf

Согласовано. Viewmodel в MVC "IS" конечный автомат для представления. Он содержит текстовый текст данных и отслеживает всю информацию выбранного элемента, а также может содержать всю логику проверки с использованием интерфейса IValidatableObject. ViewModel взаимодействует с БД на уровне модели, которая может использовать строго типизированные модели. MVVM в WPF является контроллером MVC. Но контроллер MVC намного чище, он необходим обработчику маршрутизации.
Джон Питерс

9

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


1
ИМХО я бы сказал , что «делает контроллеры более многоразовый» является слишком широким заявлением и контрпродуктивно для общих «контролеров» ASP.Net (т.е. не бизнес - логики) , поскольку эти контроллеры , как правило , содержат части приложения, которые APPLICATION- конкретный . Это представления, модели, ViewModels и бизнес-логика, которые необходимо использовать повторно. Я бы подумал, что лучше рассматривать модули бизнес-логики как поставщиков услуг, а не как контроллеров.
Ушел кодирование

Но вы говорите о «ViewModel» в Asp.net, а не о шаблоне проектирования MVVM. Две разные вещи.
Луис

9

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


Ого ... так и MVC, и MVVM пришли с SmallTalk ?? Они явно опередили свое время, очевидно ...
MattE

На самом деле, говорить, что это произошло от модели представления Мартина Фаулера, не совсем точно. Очень сложно определить, что появилось первым, но оба шаблона (если учесть, что это действительно один и тот же шаблон) были получены независимо и примерно в одно и то же время.
wekempf

6

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

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


То, что «веб-разработка» называет «MVC», является не чем иным, как разделением интересов, а не подлинным MVC, который предшествовал сети.
Терренс Браннон

4

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

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

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


4

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

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

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


4

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

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 проще для новых разработчиков.

1
Лучшее объяснение
p32094

2

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


2

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

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

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

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


2

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

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

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

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


2

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

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


1

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


1

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.