Каковы основные недостатки использования Presentation Model в коде?

Question

Я пытаюсь подготовиться к ответу на вопрос:

«Почему мы не можем просто реализовать модель представления в коде?»

На самом деле я работал над проектом, в котором мы использовали модель представления, которая была реализована в коде. Он работал довольно хорошо, мы даже смогли запустить модульные тесты на нем. Да, у вас есть зависимость от WPF в ваших модульных тестах ... но это работает!

Каковы же основные недостатки использования кода?

Я предпочитаю идею независимой ViewModel (MVVM), но в настоящее время я не чувствую возможности оправдать ее для клиентов.

Answer 1

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

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

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

Надеюсь, это поможет.

Answer 2

Простой ответ - принцип разделения интересов . Конечно, кто-то может поспорить, что, поместив модель представления в код позади, она будет отделена от представления (XAML), но я не согласен с этим. Выделенный код может «видеть» все внутренние детали представления, поскольку - это представление. И xaml, и выделенный код скомпилированы вместе в один класс, чтобы стать представлением. Они вообще не являются отдельными.

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

Концепция ViewModel довольно мощная. ViewModels могут «разговаривать» друг с другом без представления «разговоров» друг с другом или даже без того, чтобы ViewModels «ничего» не знали о представлениях.

Answer 3

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

• Серия видеороликов Майка Таулти (на самом деле их всего 10, отметьте хотя бы первое и второе)
• Джейсон Долингер в Model-View-ViewModel

Также см. Этот вопрос SO для получения дополнительных ссылок: MVVM: учебное пособие от начала до конца?

Answer 4

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

Кроме того, разделение набора навыков, только разработчики, которые знают xaml, будут вовлечены в фактическое создание представления.Позволяет вам использовать существующий в доме талант, который не знает wpf.