我是WPF的新手,正在努力学习标准成语。我有一个用户控件,允许用户输入由六个文本框组成的邮件地址。我还定义了接口IMailAddress和具体类MailAddress,后者是标准邮件地址字段的一组属性。(目前仅限美国)
我认为有一个接口意味着我可以有一些数据库类来保存关于一个人的一切,但是实现这个接口来满足这个控件的特定需要。
将此类型绑定到控件的惯用方法是什么?我当然可以将其实现为依赖属性,但对于这样的类型,这样做有意义吗?让它成为一个标准属性,然后在值发生变化时引发一个路由事件,这样会更好吗?
我不太关心这个特定的例子,而是更一般地认为这些类型的场景的最佳实践。
让您的用户控件公开IMailAddress
属性作为依赖属性是完全有效的。WPF本身也做类似的事情;例如,ItemsControl
期望您将集合绑定到它,因此它暴露了IEnumerable
类型的ItemsSource
依赖属性。
用户控件/自定义控件是表示视图的好方法,不要让MVVM怪物告诉你不是这样:)此外,没有理由这不能与MVVM完美地工作-例如:
<local:MailAddressEditor
MailAddress="{Binding Path=Customer.BillingAddress}"
/>
有一件事你可能会喜欢看,不过,是使用自定义控件而不是UserControl。这将允许你构建一个"无外观"的控件,专注于编辑地址背后的逻辑,并允许你的控件的用户独立创建渲染控件的样式。当人们使用您的控件时,他们可能会使用:
<local:MailAddressEditor
MailAddress="{Binding Path=Customer.BillingAddress}"
Style="{StaticResource SimpleInlineAddressEditor}"
/>
<local:MailAddressEditor
MailAddress="{Binding Path=Customer.BillingAddress}"
Style="{StaticResource ComplicatedAddressEditorWithGoogleMapsSelector}"
/>
在这种情况下,我们有一个控件,有两个样式(可能还有两个ControlTemplates)来给字段一个不同的布局。
自定义控件对WPF开发人员来说是一笔巨大的财富——并不是所有的事情都必须通过MVVM完成。试着保持对进入自定义控件的代码类型的意识——如果它变得有点过于逻辑化,你可能想要将其中的一些移到视图模型中。
DependencyProperties
逐渐消失,因为INotifyPropertChanged
正在接管MVVM模式。如果您希望开始在接口、数据访问和业务逻辑之间使用适当的分离,则应该查看MVVM工具包。您仍然可以使用DependencyProperties,但是我建议您构建一个ViewModel来实现与用户控件的交互。MVVM的目标之一是通过提供一个ViewModel来简化可测试性,这个ViewModel可以在xml领域之外用单元测试来验证。