CODEWITHSUNDEEP
wpfdependency-properties
Jessica Boxer
Jessica Boxer

Reputation: 543

Pattern for using dependency property for non simple type on a WPF user control

I am a newbie to WPF, and am trying to learn the standard idioms. I have a user control that allows the user to enter a mailing address, composed of six text boxes. I have also defined an interface IMailAddress, and a concrete class MailAddress that is a set of properties for the standard mail address fields. (US only for the moment.)

I figure by having an interface it means I could have some database class that holds everything about a person but implements this interface for the specific needs of this control.

What is the idiomatic way to tie this type into the control? I can certainly implement it as a dependency property, but does that make any sense with a type like this? Would I be better making it a standard property, and then raising a routed event when the value changed?

I'm not so much concerned about this specific example, but more generally what is considered best practice for these types of scenario.

Upvotes: 3

Views: 458

Answers (2)

Paul Stovell
Paul Stovell

Reputation: 32725

Having your user control expose an IMailAddress property as a dependency property is perfectly valid. WPF itself does similar things; for example, ItemsControl expects you to bind a collection to it, so it exposes an ItemsSource dependency property of type IEnumerable.

User controls/custom controls are a good way to represent views, and don't let the MVVM freakazoids tell you otherwise :) Besides, there's no reason this can't work perfectly fine with MVVM - for example:

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

One thing you may like to look at, though, is using a Custom Control instead of a UserControl. This will allow you to build a 'lookless' control that focuses on the logic behind editing an address, and allow users of your control to create Styles independently for rendering the control. When people use your control, they might use:

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

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

In this case, we have one control, with two styles (and probably two ControlTemplates) to give the fields a different layout.

Custom controls are a great asset to a WPF developer - not everything has to be done via MVVM. Just try to stay conscious of the kind of code going into your custom control - if it's getting a little too logic-y, you might want to move some of that into a view model.

Upvotes: 1

SliverNinja - MSFT
SliverNinja - MSFT

Reputation: 31651

DependencyProperties are sort of fading away as INotifyPropertChanged is taking over with MVVM patterns. You should look at MVVM toolkits if you want to start using proper separation between your interface, data access, and business logic. You can still use DependencyProperties, but I would recommend you build a ViewModel to implement your interactions with your user control. One of the goals of MVVM is making testability easier by providing a ViewModel that can be verifed with unit tests outside of XAML-land.

A great starter MVVM toolkit for WPF is MVVM Light. A heavier weight MVVM toolkit would be Prism.

Upvotes: 0

Related Questions