Шаблон для использования свойства зависимости для непростого типа в пользовательском элементе управления WPF

Question

Я новичок в WPF и пытаюсь выучить стандартные идиомы.У меня есть пользовательский элемент управления, который позволяет пользователю вводить почтовый адрес, состоящий из шести текстовых полей.Я также определил интерфейс IMailAddress и конкретный класс MailAddress, который представляет собой набор свойств для стандартных полей почтового адреса.(США только на данный момент.)

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

Какой идиоматический способ привязать этот тип к элементу управления?Я, конечно, могу реализовать его как свойство зависимости, но имеет ли это смысл для такого типа?Не лучше ли сделать его стандартным свойством, а затем вызывать перенаправленное событие при изменении значения?

Меня не очень беспокоит этот конкретный пример, но в более общем плане, что считается наилучшей практикой для этих типовсценария.

Answer 1

Наличие в вашем пользовательском элементе управления свойства IMailAddress в качестве свойства зависимости совершенно допустимо.Сам WPF делает подобные вещи;например, ItemsControl ожидает, что вы привяжете к нему коллекцию, поэтому он предоставляет свойство зависимости ItemsSource типа IEnumerable.

Пользовательские элементы управления / пользовательские элементы управления являются хорошим способом представления представлений, и не позволяйте freakazoids MVVM сказать вам иначе :) Кроме того, нет никаких причин, по которым это не может прекрасно работать с MVVM - например:

<local:MailAddressEditor
  MailAddress="{Binding Path=Customer.BillingAddress}"
  />

Тем не менее, вам может понравиться использование Custom Control вместо UserControl.Это позволит вам создать элемент управления «без внешнего вида», который фокусируется на логике редактирования адреса, и позволит пользователям вашего элемента управления создавать стили независимо для рендеринга элемента управления.Когда люди используют ваш элемент управления, они могут использовать:

<local:MailAddressEditor
  MailAddress="{Binding Path=Customer.BillingAddress}"
  Style="{StaticResource SimpleInlineAddressEditor}"
  />

<local:MailAddressEditor
  MailAddress="{Binding Path=Customer.BillingAddress}"
  Style="{StaticResource ComplicatedAddressEditorWithGoogleMapsSelector}"
  />

В этом случае у нас есть один элемент управления с двумя стилями (и, возможно, двумя ControlTemplates) для придания полям разного макета.

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

Answer 2

DependencyProperties как бы исчезают, так как INotifyPropertChanged вступает во владение паттернами MVVM. Вам следует взглянуть на наборы инструментов MVVM , если вы хотите начать использовать правильное разделение между вашим интерфейсом, доступом к данным и бизнес-логикой. Вы по-прежнему можете использовать DependencyProperties, но я бы порекомендовал вам создать ViewModel для реализации ваших взаимодействий с вашим пользовательским элементом управления. Одна из целей MVVM - облегчить тестируемость, предоставив ViewModel, которую можно проверить с помощью модульных тестов вне XAML-земли.

Отличный стартовый набор инструментов MVVM для WPF: MVVM Light . Более тяжелый инструментарий MVVM будет Prism .