Наконец, чтобы сделать некоторые разработки Silverlight, и я наткнулся на MVVM. Я знаком с MVC и статью, которую я читал, сказал, что из-за XAML MVC не получится. Не слишком много опыта в XAML явилось причиной того, что я не понял этого.
Может кто-нибудь объяснить, почему MVC не подходит и почему MVVM лучше для разработки Silverlight?
Спасибо JD
Это очень тонкое различие, которое я могу объяснить лучше всего, сравнивая MVC в ASP.NET и MVVM в WPF.
В ASP.NET MVC запрос поступает с веб-сервера и обрабатывается непосредственно контроллером. Контроллер определяет соответствующий View и заполняет его с помощью моделей. Затем контроллер выдает эти экземпляры в базовую систему, которая возвращает результат клиенту. Вы можете видеть, что контроллер работает первым и последним.
В MVVM пользовательский интерфейс (вид) обращен к пользователю и принимает вход пользователя напрямую. Внутри представления в этой функции активируются команды в ViewModel (который является DataContext представления). Элемент управления переходит в ViewModel, который интерпретирует то, что его отправил, и готовит его Модели. После того, как управление возвращается к представлению, оно обновляется в соответствии с изменениями в Модели. Если требуется новый просмотр, ViewModel связывается с ним с помощью NavigationService (или любого другого способа навигации, используемого вашим приложением), который является областью компонентов Window или Frame - UI. Вы можете видеть, что ViewModel не первый и последний, чтобы действовать; представление играет гораздо большую роль, чем в MVC.
Архитектура WPF/Silverlight является причиной того, что все делается так. Контрольная панель не может управляться/заменяться командами, привязанными и навигационными инфраструктурами; они тесно интегрированы с пользовательским интерфейсом. Таким образом, контроллер должен сидеть ниже просмотра и принимать более пассивную роль.
MVVM был разработан главным образом из-за XAML и упростить привязку данных, он очень похож на MVP. Основными преимуществами являются более простой способ манипулирования пользовательским интерфейсом (ViewModel или Presenter заботятся об этой задаче, а не модели, которая должна запускать события в представлении после того, как она была обработана контроллером).
Лучшие две статьи, с которыми я столкнулся, помогли мне понять принципы: MVC vs MVP vs MVVM и MVVM для Tarded Folks Like Me или MVVM и что это значит для меня
Компоненты развязки
В MVC у вас есть треугольная связь между компонентами. То есть: Контроллер владеет представлением и моделью. Взгляд опирается на определение Модели. Модель должна удовлетворять требованиям View. Подумайте о концентраторе (контроллере) и архитектуре спикера (вид и модель).
В MVVM подумайте о том, что треугольник сглаживается с каждым компонентом, только знающим друг о друге в цепочке. То есть: View- > ViewModel- > Model
Модель ничего не знает о стеке. ViewModel знает только модель Вид знает только модель просмотра - он не знает о модели.
Почему это важно?
Это ядро исходного вопроса.
Основная цель - дальнейшая абстракция вашей архитектуры. Обычно это приведет к еще большему количеству кода, но меньше точек соприкосновения между объектами. Меньше точек соприкосновения важно, потому что это приводит к более гибкому коду. Чем больше сцепление/контакт класса А с классом B, тем больше влияние на изменение класса A. Снижение влияния изменений является одним из ключевых преимуществ хорошей архитектуры.
Чтобы полностью понять это, полезно подумать о том, что представляют собой компоненты. Что такое View, контроллер, ViewModel или модель? Являются ли они буквальными определениями или более абстрактными понятиями?
По моему опыту, было более полезно рассмотреть Модель как кластер классов/объектов, которые касаются построения и сохранения данных. Это не просто простой объект со свойствами. Это класс, который выполняет выборку данных, сохраняет данные, factory, который строит простые старые объекты. Это фасадный слой, который обеспечивает прозрачный API в данных. Следует ли ссылаться на этот фасадный слой непосредственно из представления?
По-моему, этого не должно быть. В MVC этот ответ также "нет". Контроллер извлекает данные из модели. В этом отношении MVC и MVVM достигают той же цели. Если две архитектуры отличаются друг от друга, то как связаны данные и представление.
Как и модель, представление может представлять собой набор классов, которые по согласованию друг с другом отображают представление представления. Это может состоять из View Controller + View в случае мобильных платформ (View Controller on iOS, Activity on Android). Во многих случаях вам нужен класс для загрузки документа вида в память и обновления свойств представления. Здесь много работы. В MVC контроллер быстро становится классом "кухонный раковина" - своего рода демпинговая площадка для всего, что связано с текущим контекстом пользователя.
Когда вы умножаете это на десятки потенциальных представлений в своем приложении, вы получаете множество глубоких зависимостей между вашим исходным кодом модели и вашим интерфейсом View Code. С большими классами контроллера эти зависимости не сразу очевидны.
Сглаживание ваших зависимостей
MVVM выравнивает зависимости. Это создает фокус. Что такое фокус? Возможность работать с одной функциональностью без отвлечения всех других зависимостей. Теперь вы можете начать писать модульные тесты по коду, который ранее считался неустойчивым.
Модель View действует как фасад между представлением и моделью. Модель View удовлетворяет потребностям View - технически View должен обладать View Model. Если View требует данных из нескольких источников, View Model инкапсулирует состав отдельных источников данных в единый унифицированный, ненормированный объект. Если представление необходимо перезвонить в модель или другие пункты назначения, модель просмотра отобразит крючки и направит соответствующий вызов.
Посмотрите, как работает сетевая панель. На первый взгляд это кажется излишним - почему бы просто не подключить ваш ethernet от точки A к точке B. Но с опытом вы поймете, что панель патчей предоставляет вам ключевую часть абстракции, которая позволяет вам изменять маршруты Point B, не влияя на точку A. Это то, что делает ваша модель просмотра.
Теперь, когда у вас есть чистая абстракция между вашим представлением и моделью, последствием должно быть то, что ваш View/Controller связан только с представлением. Это означает, что он не должен заниматься локализацией или форматированием - он получает данные и представляет данные. Ваша модель просмотра - идеальное место для такого рода массива данных предварительного просмотра. Скажем, вам нужно отфильтровать данные на основе критериев. Опять же, модель просмотра знает о данных модели (ваш вид не является) и является отличным местом для размещения такого кода.
Как только вы начнете упорядочивать требования к приложениям таким образом, ваш код View/Controller становится более чистым, и когда что-то нужно изменить, последствия более очевидны, что приводит к меньшему количеству ошибок.
Тестируемость
Последнее замечание по тестируемости: путем сглаживания зависимостей, это облегчает вложение ложных зависимостей в ваши тесты. Это упрощает и упрощает тестирование. Ваша модель просмотра становится чем-то, что вы можете определить явные тестовые примеры.
Я думаю, идея состоит в том, что MVVM лучше подходит для XAML, чем MVC. Выражение MVC "не подходит" немного преувеличено.
И почему MVVM лучше? Главным образом из-за превосходной привязки данных и связывания команд в XAML. См. в этой статье.
Я думаю, что другое преимущество - это кривая обучения. Поскольку большинство разработчиков в frontend-технологиях используют стиль кодирования MVVM, им легче адаптироваться к модели контроллера, где им необходимо передать каждый запрос из представления в контроллер и связать его с Model.