WPF：数据绑定对于模式对话框是否有意义？

Question

（我对WPF还是很陌生，所以这个问题可能看起来很明显或不一致。）

要求从子模式窗口中编辑一些应用程序的基础业务数据，并且仅当用户在此窗口中按“确定”按钮时才更新数据。我们将此窗口称为“设置对话框”。

在这种情况下，使用WPF数据绑定将SettingsDialog的控件绑定到业务数据是否仍然合理？（如果是这样，那么仅在用户按下SettingsDialog的“确定”按钮时如何更新业务数据？）

还是最好在显示SettingsDialog时从业务数据中手动分配SettingsDialog控件的值，然后仅在用户按下OK按钮时才将其分配回来？

正确选择的参数是什么（较小或更清晰的代码，性能，可扩展性）？

类似情况是否存在一些公认的设计模式？

编辑：我将Bubblewrap的答案标记为已接受，因为它最适合我自己的具体情况。虽然，Guard和John的回答似乎也可以接受。

总结一下：使用数据绑定具有一些优点。它允许SettingsDialog对业务对象内部连接和依赖性（如果有）一无所知，允许稍后轻松地从模式模式切换到非模式模式，减少GUI和业务数据之间的依赖性。

为了在单击OK按钮时实现对象更改，可以使用对象克隆/分配，或者对象可以实现IEditableObject接口。

但是，在某些琐碎的情况下，使用数据绑定可能会产生一些不必要的开销。

Answer 1

我以前遇到过类似的需求，并且更喜欢两种变体，都使用数据绑定。

在第一个变体中，我们克隆对象并绑定到克隆。当用户按下“确定”时，克隆对象将替换为真实对象。当一次编辑一个对象并且该对象不被其他对象直接引用时，这非常有用。如果它被引用，那么您可以将克隆中的值复制到原始值，以便引用保持不变。这可以节省工作，因为编辑器中不需要额外的工作，最多您必须在对象上定义 2 个方法，一个 Clone 和一个可能的 Apply 方法来从克隆中复制值。

第二个变体我们绑定到原始对象，但我们将原始值存储在编辑对话框中，或者在本地字段中，或者在临时数据对象中。当用户按“确定”时，不会发生任何特殊情况，但当用户按“取消”时，我们会恢复这些值。当您仅在对话框中编辑几个简单属性时，这非常有用。

我更喜欢数据绑定解决方案，因为它不会用应用/取消逻辑污染编辑对话框，如果在编辑器中实现，则非常依赖于您的 XAML：可以重命名控件，可以用文本框替换组合框等，所有这些都会影响手动从控件分配数据的代码。

Clone/Apply 方法只需要在您的业务对象上，理论上比您的 UI 编辑器更稳定。即使 XAML 发生更改，在大多数情况下您的绑定也可以保持不变。例如，从组合框更改为文本框仅意味着您绑定到 Text 而不是 SelectedValue，但实际绑定是相同的。