Привязка к модели или ViewModel [закрыто]

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

Особенно те, что здесь:Вопрос 1,Вопрос 2 и конечноQuestion3 поэтому, пожалуйста, не закрывайте этот вопрос слишком быстро, Они там ответят просто скажутСделай это, сделай это " и не почему!

Есть люди, которые тамОтрицать необходимость вViewModel и сказать, что "стандарт» способ привязки к модели напрямую, Это то, что я отрицаю и пытаюсь доказать техническими аргументами.

Из моего фона в,MVCMVPPresentation Model, это просто естественно для меня, чтобы использовать.ViewModelВозможно, я упустил важный момент?

Так что для меня по умолчанию это привязка кViewModelнезависимо от того, чтоModel есть (и не важно, реализует ли онINotifyPropertyChanged или нет).

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

1. Удаление логики из вида

Сделайте логический блок тестируемымуменьшить избыточность кода (дублирование при необходимости)

2. Безопасность

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

3. Слабая связь

Если привязка напрямую к модели, между нижними уровнями и видом будет связьИзменение модели вызывает изменения во всех видахВид не зависит от конкретной моделиМодель может быть легко сгенерирована с помощью EF, некоторых DSL, пакетных файлов и т. Д.

4. Скорость разработки

Вы можете начать сPrototype ViewModel иерархия и привязать к этомуЕсли модель все еще находится в стадии разработки, вы можете начать сPrototype ModelModel а такжеViewModel может быть разработан testdriven, независимо от видаView может быть полностью построен дизайнером или разработчиком с большим опытом проектирования

5 "Хитрая синхронизация " решено

Есть много решений для любого конкретного "хитрая синхронизация " проблема, напримерAutoMapperСистема событий из модели (модель запускает событие, подписывается ViewModel)

6. Равная структура на протяжении всего проекта

Есть точки, где есть ViewModel, как SelectedItemСмешивание привязки к модели и ViewModel является ошибкойНовичкам сложнее понять структуру проектаначать приносить ViewModel позже, когда нет никакого пути, это грязно

7. Масштабируемость

Давайте определим: если вы не используете ViewModel, это не MVVMMVVM может быть легко адаптирован к множеству источников данных, множеству просмотровЕсли вы обнаружите какие-либо проблемы с производительностью: отложенная загрузка и кэширование выполняются во ViewModel

8. Разделение интересов

Получение контроля над сложностью является основной проблемой в программном обеспеченииЕдинственная ответственность ViewModels заключается в продвижении измененийОтправлять уведомления представлению так же просто, как отправлять его на другой процесс или компьютер.ViewModel, а не регистр View для уведомлений об изменениях в модели / источнике данныхисточник данных может игнорировать отправку событий ViewModel, которые вызвали изменение

Наоборот, мужик издругая нить сбрасывает некоторые точки, в том числе

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

Если у модели есть собственное уведомление об изменении свойства, # 1 и 2 aren 'это проблема. Вместо этого вам нужно беспокоиться об утечках памяти, если виртуальная машина-оболочка выходит из области видимости, но модель этого не делает.т.

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

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

Итак, вопрос в том, что является стандартным способом связывания и почему?

Я пропускаю пункты, которые делают необходимым иметь ViewModel?

Есть лиреальный причины, по которым хочется привязаться к модели?

Наиболее важным являетсяЗачем, а не как.

Ответы на вопрос(6)

Ваш ответ на вопрос