.net - WPF 中的数据绑定(bind)以何种方式改进了过去的框架？

Question

与过去的数据绑定(bind)框架相比，WPF 数据绑定(bind)框架从根本上发生了哪些变化？

我从根本上强调这个词，也就是说架构而不是技术。当然它带来了改进，但我更感兴趣的是此类框架的进化性、可维护性和可扩展性以及 AGNOSTICISM (PORTABILITY)，即我处于 PARADIM 级别。

与以前的数据绑定(bind)框架相比，为什么我在任何地方都看不到一些真正抽象出 WPF 数据绑定(bind)本质的 UML 模式，看看它是否确实只是技术，或者它是否是真正的 PARADIGM 改进。

Answer 1

来自 Windows 窗体世界，这些是我到目前为止发现的 WPF 数据绑定(bind)的优点:

1. DataContext 和绑定(bind) Path 是单独指定的，一个绑定(bind)去寻找它的 DataContext 如果它本身没有指定，则以分层方式(与其父级)。

   这样做的好处可以看出，例如使用 ListView 和 DataTemplate；前者可能指定数据源 (DataContext)，而后者定义源项的属性(通过 Path 指定)将如何显示。

   (这有一个可能的问题，顺便说一句:据我所知，XAML 中没有办法确保在编译时 DataContext 和 Path 都引用相同类型的对象。)

2. 路径可能比简单的属性名称更复杂。这在绑定(bind)到 XML(您可以指定一个 XPath 表达式来引用数据)而不是绑定(bind)到 POCO 时可能最有用。

3. WPF 似乎没有一些关于 Windows 窗体数据绑定(bind)的恼人问题:

   • 查看我之前的问题 Winforms data-binding to business objects in a multi-threaded scenario without InvokeRequired? — IIRC，即使使用 WPF，仍然需要一些工作才能正确地从后台线程获取 更新(通过 Dispatcher)，但据我所见，事情是比 Winforms 更好。我记得 Jason Dolinger's video on the MVVM pattern 中显示了一个示例.
     
     ( 已编辑:在这方面，自 Winforms 以来，事情实际上并没有太大变化。BeginInvoke 只是被 Dispatcher 类，这使表面上的事情变得更好一些，但从根本上讲，它仍然是相同的机制。)

   • Winforms data binding: Can a TypeConverter be used instead of the Format/Parse events? — 通过绑定(bind)完成的 值转换比使用 Winforms 更容易，因为可以在 XAML 中直接指定值转换器；在 Winforms 中，您只能通过绑定(bind)本身定义的 Format/ Parse 事件进行值转换；您不能直接在 Windows 窗体设计器中指定值转换器。因此，您需要在代码隐藏中设置绑定(bind)；这意味着您需要按名称引用 UI 控件；这至少部分打破了 View 和 Presenter 的分离(如果您 尝试使用 MVP 模式)。不好。

4. 命令 在 Winforms 中不存在。您必须在后台代码中使用事件和事件处理程序，而不是命令(例如 saveButton_Clicked)。现在，如果您想将所有逻辑委托(delegate)给 Presenter 类(同样，在 MVP 设置中)，您将必须手动将事件(例如单击按钮)从 View 转发到 Presenter。在 WPF 中，数据绑定(bind)由 ICommand/ RoutedCommand 的可用性补充，这使得这个过程更加容易。