WPF中的数据绑定以什么方式改进了过去的框架？

Question

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

我强调术语从根本上，即架构不是技术。当然它带来了改进，但我对这些框架的进化性，可维护性和可扩展性以及AGNOSTICISM（PORTABILITY）更感兴趣，那就是我在PARADIM层面。

为什么我无法看到一些UML模式真正抽象出WPF数据绑定的本质，与之前的数据绑定框架相比，看看它是否只是技术，还是真正的PARADIGM改进。

Answer 1

来自Windows Forms世界，这是我迄今为止找到的WPF数据绑定的优点：

1. DataContext和绑定Path分别指定，并且绑定会以分层方式查找其DataContext（与其父级一起） ）如果它没有指定一个。

   可以看出这样的优点，例如使用ListView和DataTemplate s;前者可以指定数据源（DataContext），后者则定义如何显示源项的属性（通过Path指定）。

   （这有一个可能的问题，顺便说一下：AFAIK，在编译时，XAML无法确保DataContext和Path都引用相同类型的对象。）

2. Path可能比简单的属性名称更复杂。这在绑定到XML时可能最有用（您可以指定XPath表达式来引用数据），而不是绑定到POCO。

3. WPF在Windows Forms数据绑定上似乎没有一些恼人的问题：

   • 查看我之前提出的问题 Winforms data-binding to business objects in a multi-threaded scenario without InvokeRequired? - IIRC，从背景线程获取更新仍需要一些工作（通过{{ 1}}）即使使用WPF，但从我所看到的情况来看，事情比Winforms更好。我记得Jason Dolinger's video on the MVVM pattern中有一个例子。
     
     （ 已编辑：在这方面，自Winforms以来，事情实际上并没有发生太大变化。Dispatcher已经被BeginInvoke类所取代，在表面上有点好，但从根本上说它仍然是相同的机制。）

   绑定完成

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

Winforms中不存在

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