Связывание WPF против обработки событий

Question

Я новичок в WPF и пришел из опыта работы с WinForms и имею довольно простой вопрос о связывании и обработке событий.

Чтобы попытаться сохранить некоторое разделение ответственности, у меня есть куча Presentation объектов, которые просто имеют Dependency Properties для хранения частей данных пользовательского интерфейса бизнес-объекта, бизнес-объект содержит аналогичные данные, но типы данных иногда отличается, так что объект Presentation подходит для отображения. Так что-то вроде

public class MyPresentation
{
   // bunch of dependency properties
   public bool MyProperty
   {
      get { return (bool)GetValue(MyPropertyProperty); }
      set { SetValue(MyPropertyProperty, value); }
   }

   // Using a DependencyProperty as the backing store for MyProperty.  This enables animation, styling, binding, etc...
   public static readonly DependencyProperty MyPropertyProperty =
   DependencyProperty.Register("MyProperty", typeof(bool), typeof(MyPresentationObject), new UIPropertyMetadata(false, MyPresentationObject.MyPropertyPropertyChanged));

   MyBusinessObject RelatedBusinessObject { get; set;}

   public MyPresentation(MyBusinessObject businessObejct)
   {
      this.RelatedBusinessObject = businessObject;
   }


   public static void MyPropertyPropertyChanged()
   {
      // Do some stuff to related business objects
   }
}

Свойства MyPresentation являются данными, привязанными к различным элементам управления, и я использую Trigger s и т. Д., Чтобы изменить свойства зависимости представления, что вызывает изменения бизнес-объекта в OnPropertyChanged событии

У меня вопрос: правильно ли я использую привязку? Обычно (в Winforms) я бы использовал события щелчка и т. Д., Чтобы изменить значения своих бизнес-объектов (или их версий презентации), но события такого рода и обработка событий такого рода кажутся излишними, когда вы можете использовать Binding, Trigger с и OnPropertyChanged события.

Я что-то упустил?

Answer 1

Вы пишете дополнительный код, который вам не нужно писать.

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

Во-вторых, вам не нужны свойства зависимостей для объекта презентации, стили и анимация для бизнес-объектов просто не имеют смысла, и вы можете «подключиться» к объекту UI -> презентации, просто написав обычные ежедневные сеттеры для вашего свойства.

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

Answer 2

Посмотрите здесь здесь представлен шаблон Model View ViewModel, он позволяет вам в полной мере использовать преимущества связывания и Command of WPF, не мешая вашим бизнес-объектам (например, реализации таких вещей WPF, как INotifyPropertyChanged, в вашем бизнесе. объекты)

Answer 3

Вы правильно используете привязки таким образом. Также проверьте шаблон Представление Модель-Представление модели, так как он похож на то, что вы делаете, но более определим. Также проверьте интерфейс INotifyPropertyChanged - это более приемлемый способ отловить, что свойство изменилось локально, и уведомить представление (вашу форму), что объект изменился. Таким образом, вы получаете лучшее из обоих миров: изменения в объектах могут произойти в результате нажатия кнопки или привязок.

Answer 4

По моему опыту, обычный шаблон состоит в том, чтобы просто использовать презентационный / бизнес-объект, который реализует INotifyPropertyChanged .

Редко возникает необходимость реализовать ваш бизнес / презентационный объект как DependencyObject или с прикрепленным DependencyProperties , поскольку для привязки данных в WPF требуется только одна сторона привязки, чтобы быть DependancyObject (в данном случае ваши элементы управления) - другая сторона может, а в случае бизнес-объектов обычно должна быть POCO. В противном случае вам в конечном итоге придется загрязнять свои бизнес-объекты классами WPF без необходимости.

Также создание ваших объектов DependencyObjects , вероятно, излишне, потому что вы не будете анимировать, стилизовать, шаблонизировать их значения и т. Д.

Ура, Jack

Answer 5

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

Кстати, я уверен, что у кого-то будет мудрость MVC, чтобы сделать все еще проще.