Эксперты MVVM нуждаются в вашем мнении о MVVM и Dataforms

Question

Насколько я понимаю, ViewModel должна абстрагировать модель от представления и добавить дополнительную логику для обработки материала презентации.

Мой вопрос:

Как бы я создал форму данных, которая должна обрабатывать пользовательский ввод для заказа и деталей одновременно. Должны быть представлены поля для ввода заказов, а также поля для 1 детализации.

Моя модель будет иметь объект для заказа, который содержит список OrderDetails.

Как будет выглядеть моя ViewModel для моей OrderEntryForm?

Буду ли я иметь OrderViewModel и OrderDetailViewModel и мой мой OrderEntryForm будет содержать свойство OrderViewModel и один для OrderDetailViewModel? (вложенность ViewModels?) Как будет проходить валидация в этом случае? Так как валидация должна подходить близко к модели? Особенно, когда я работаю с РИА-Сервис ... Разве не имеет смысла помещать его во ViewModel?

Как далеко вы бы абстрагировали модель от ViewModel? Пример:

 private DateTime _OrderDate;
        public DateTime OrderDate
        {
            get { return _OrderDate; }
            set
            {
                if (_OrderDate != value)
                {
                    _OrderDate = value;
                    OnPropertyChanged("OrderDate");
                }
            }
        }

это означало бы, что я должен сопоставить ViewModel-Property с Model-Properties. Здесь нельзя использовать логику проверки из модели ...

Этот пример:

 public DateTime OrderDate
        {
            get { return Model.OrderDate; }
            set
            {
                if (Model.OrderDate != value)
                {
                    Model.OrderDate = value;
                    OnPropertyChanged("OrderDate");
                }
            }
        }

потребуется передать в модель. Иметь доступ к логике проверки модели, но также и к соединению ...

Большинство примеров в Интернете показывают формы данных, которые используют ViewModel, что просто представление таблиц, а не реальная абстракция ...

Я знаю, и я видел это

stackoverflow.com / вопросы / 744474 / комбинируя-нетто-RIA-сервисов и-MVVM-в-Silverlight-3-0

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

Я знаю много вопросов ...

Что вы думаете по этой теме? Как бы вы обрабатывали сложные формы данных?

Answer 1

Как это часто бывает с шаблонами, это действительно зависит. ViewModel может раскрыть базовую модель, и нет строгого и быстрого правила, которое говорит, что вы «должны» все спрятать и делегировать. Я говорил со многими людьми, которые являются строгими приверженцами LOD, и все же они согласны с тем, что в случае привязки пользовательского интерфейса это не применяется.

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

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

Что касается дочерних моделей, таких как OrderDetail, то, если дочерней модели достаточно просто связать ее, просто представьте ее напрямую. Теперь следует рассмотреть вопрос об уведомлении: если ваша модель не реализует INPC, у вас может не быть иного выбора, кроме как обернуть его для правильной работы привязки.

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

Например

public class OrderDetailViewModel
{
  public OrderDetail OrderDetail {get;set;}
  public bool IsValid {get;set;}  
}

Где IsValid проверяет некоторую логику, специфичную для экрана.

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

НТН Гленн

Answer 2

Крис,

У меня возникла та же проблема, и в итоге я реализовал ее дурацким способом :-( (две vieModels по одной на представление, но передача родителя дочернему View ... плохие вещи).

Из моей ошибки я узнаю, что в следующий раз я попробую:

• Создайте одну ViewModel, но в дочернем представлении передайте подробный объект в текстовом данных (этот подробный объект не должен совпадать с созданными прокси-объектами, возможно, является контейнером этих объектов).

• Генерация класса одноэлементного контроллера: этот класс не будет открыт для представления, он будет прозрачным для представления, просто модель подробного представления будет запрашивать у контроллера эти зависимые данные вместо перехода в DAL .

  Не уверен, что это будут чистые решения, нужно попробовать и потерпеть неудачу:).

  Я согласен с вами ... реальных примеров с такими сценариями нет.

  Что вы думаете?

  Спасибо Braulio

  PS: Что касается проверки, если мы создадим наши собственные супер сущности, мы сможем там определить нашу валидацию, в моем случае я попытался также расширить сущности, используя частичные случаи, и тогда у меня может быть сущность myPhoneNumberDetail с моей специальной проверкой.

Answer 3

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

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

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

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

В моем примере я непосредственно использовал тип DAL, чтобы упростить и не перегружать понятия в одном образце. Я хочу специально вести блог о моделях презентаций и проекциях ... и поэтому не хотел одновременно смешивать публикации служб viewmodel и .net ria с концепциями моделей презентаций.

Answer 4

Для пояснения, ВМ - это абстракция Модели, а не Представления и не наоборот.

Вы, безусловно, можете использовать несколько виртуальных машин, чтобы соответствовать отдельным частям вашего View. Если вам не понадобятся отдельные виртуальные машины для Order и Details, вы можете просто использовать OrderAndDetialsViewModel, который содержит все, и весь View будет привязан прямо к этому. Вот тут и приходит абстракция.

Вы правы, что логика проверки вашей модели будет отличаться от логики проверки вашей ViewModel, если вы ее там поместите. Ни при каких обстоятельствах проверка не будет в представлении.

Я не уверен, что следую вашему второму примеру. Что является объектом Model? Ваша ВМ может знать о Модели (ях), из которых она составлена, но она не собирается выставлять ее / их как таковые непосредственно Представлению.

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