TwoWay或OneWayToSource侦听中的更改目标属性并传播它们回到源头。这被称为更新源。通常，这些只要目标属性更改。这对复选框和其他简单控件，但它通常不适合文本字段每隔更新一次按键会降低性能并且它拒绝用户正常后退和修正的机会在提交到之前键入错误新价值。因此，默认文本的UpdateSourceTrigger值属性是LostFocus而不是属性已更改。
我知道，在更新直接进入数据库或通过网络的情况下，或者如果它是一个非常大的数据量，在TextBoxes上使用UpdateSourceTrigger=PropertyChanged确实会降低性能。
但是，如果它只是更新一个简单的DependencyProperty，或者实体框架对象的属性(在提交之前(，那么性能打击是否可以忽略不计？
只是想知道，因为我正在创建一个WPF应用程序，它可以跟踪正在编辑的对象的状态，并根据是否进行了更改来优化"保存"按钮的外观。我认为确定更改的最简单方法是在适当的时候捕捉相关的SourceUpdated事件。当文本框的UpdateSourceTrigger=PropertyChanged时，它的工作效果最佳，因为用户会得到即时反馈，认为存在"可保存"的更改。
警告您性能下降的原因是，在大多数情况下，如果您需要在每次击键时更新源属性，那是因为您需要在属性值更改时发生一些事情。毕竟，如果你不需要发生这种"事情"，你就不会真正关心房产何时更新，只要它最终更新了。
对性能的真正影响完全取决于"东西"是什么。这完全取决于您的应用程序。如果那个"某物"正在格式化并显示另一个TextBlock中的值，那么在每次击键时都这样做可能不会引起注意。如果它过滤一个10000行的DataTable并刷新绑定到它的DataGrid，它可能会。
那你怎么说呢？有两种方法：
1( 了解您的应用程序。如果您知道在更新源属性时应用程序在做什么，您就可以预测在每次击键时做这件事是否会成为一个问题。当你说"我想我想知道它一开始看起来是否很好，但在我不知道的某些情况下确实会引起问题"时，你真正想说的是，"如果用户按键时我不知道我的应用程序在做什么，会发生什么？">
2( 如果您不知道用户按键时应用程序在做什么，请对其进行评测。
如果它适合您的应用程序，并且您没有注意到性能显著下降，那么将UpdateSourceTrigger设置为PropertyChanged是没有问题的。事实上，如果您使用的是像Caliburn.Micro这样的MVVM框架，那么它会将其设置为所有TextBoxes的默认设置。