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

Question

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

Я думал о создании своего приложения с использованием нескольких вложенных представлений.Таким образом, у меня есть одно представление и модель представления для полной сущности, но она содержит несколько представлений и модели представления для различных свойств.Это хороший подход?Или я столкнусь с большим количеством проблем в будущем?

Дополнительно: как бы я их подключил?Привязать ли я Datacontext вложенных представлений к «сущностям» («реальным» объектам из домена) или ViewModels, созданным так называемым «родительским» ViewModel?

Должен ли я использовать инфраструктуру MVVMтакие как MVVM Light, Prism или Caliburn.Micro?

Answer 1

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

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

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

Я использовал все три платформы MVVM, которые вы упомянули, иРекомендую идти с Caliburn.Micro или MVVM Light.Призма может быть немного подавляющей и имеет гораздо более крутой кривой обучения.

РЕДАКТИРОВАТЬ

На основании вашей дополнительной информации, в предположении:

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

Затем вы можете сделать что-то вроде:

• Создание пользовательских элементов управления для каждого сложного свойства, представляющего подмножество сущности документа.Каждый пользовательский элемент управления может иметь свою собственную ViewModel с логикой для редактирования данных.
• Создайте базовое представление (Shell) и макет, в который будет вставлен каждый из пользовательских элементов управления;используйте ContentControl для контейнера каждого из этих пользовательских элементов управления в командной консоли.ViewModel из Shell будет отвечать за внедрение различных пользовательских элементов управления в каждый из ContentControls.
• Создание контроллера, который будет выполнять тяжелую работу для объекта документа, т. Е. Получать новый, обновлять и т. Д..
• Когда какой-либо пользовательский элемент управления изменяет данные, отправьте их обратно контроллеру, который обновит объект документа, а затем передаст новый объект всем;Здесь вы будете использовать модель pub / sub.

Это действительно не имеет значения, если вы используете Caliburn.Micro или MVVM Light;они оба обеспечивают хорошую основу для базовой сантехники.Иди с тем, что тебе удобнее всего.

Answer 2

Что вы получите от моделей с комбинированным представлением?Являются ли те свойства, которые вы хотите обернуть в отдельные модели представлений, такими сложными ?Например, будут ли сценарии, когда вам понадобятся более сложные модификации / обработка, скажем, MainViewModel.PropertyX?

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

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

Prism, MVVM Light ..?

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

Редактировать:

Учитывая, что ваша модель довольно велика, она идеально подходитсмысл разделить это.Я также предлагаю создать выделенные пары модель / представление для сущностей, из которых состоит ваша основная сущность (документ).Привязка к моделям может показаться привлекательной, но чаще всего вы будете сожалеть об этом решении.Проще говоря:

• модель отдельного представления для сущностей, в которых она имеет наибольшее значение (может идти с all , но обычно это суждение - "Мне действительно нужноновая модель представления для этого объекта, предоставляющая одностроковое свойство? ")
• отдельные представления, соответствующие моделям представления
• модель основного вида (документ), представляющая частичноепросмотр моделей в качестве привязываемых свойств
• основной вид настройка частичный просмотр DataContexts для частичного просмотра моделей, взятых из основного