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

Question

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

Мой вопроса:

Как создать DataForm, который предполагает, чтобы обрабатывать ввод данных пользователя для заказа и деталей сразу. Он должен содержать поля для ввода заказов, а также поля для 1 детали.

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

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

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

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

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

это означало бы, что я должен сопоставить ViewModel-недвижимость в Model-Properties. Не удается использовать Validation-Logic от модели здесь ...

Этот пример:

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

бы requiere пройти в модели. Иметь доступ к логике проверки модели, но и в связи ...

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

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

stackoverflow.com/questions/744474/combining-net-ria-services-and-mvvm-in-silverlight-3-0

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

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

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

Answer 1

Чтобы уточнить, VM является абстракцией Модели, а не View, а не наоборот.

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

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

Я не уверен, что следую вашему примеру. Что такое is Объект модели? Ваша ВМ может знать о Модели, из которой она составлена, но она не будет подвергать ее/их как таковые непосредственно в представлении.

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

Answer 2

Крис,

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

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

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

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

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

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

  Как вы думаете?

  Благодаря Braulio

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

Например

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

Где IsValid проверяет некоторый экран конкретной логики.

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

HTH Гленн