这更像是一个架构/设计问题。
我过去遇到过一些用 WPF/Windows Forms 等编写的项目，这些项目具有包含很多字段的复杂屏幕，并且这些字段相互连接(它们的值相互依赖，涉及一些逻辑).
这些项目是我在实现后接手的，我发现很多事件/数据绑定(bind) hell - 我的意思是因为所有这些字段都依赖于其他人，所以他们已经实现了 INotifyPropertyChanged 并且其他领域正在结果修改。这会导致相同的字段在屏幕加载时被更新 5-6 次，并且填充字段的顺序会导致可怕的错误。 (例如，日期设置在工作类型之前，而不是在工作类型之后，所以我最终得到了不同的工作费用.)
更糟糕的是，一些 hack 是在 UI 事件上实现的(例如，DropDown 更改为更新字段 X)，而其他 hack 是在 UI 绑定(bind)到的域模型中实现的。
基本上，这是一团糟，我只想知道如果我要从头开始，实现这样的东西的最佳方法是什么。还是一开始就避免使用如此复杂的屏幕是个好主意？
最佳答案
我会尽量将业务逻辑排除在属性 setter 之外。
首先，如果一次计算需要多个属性，我会编写一个执行计算的方法，并在适当的时候调用该方法。例如。如果属性值的所有不同组合都有意义，则可以只调用每个属性的 setter 中的方法，确保在任何一个属性发生更改时运行相同的代码。如果您只能评估属性值的特殊组合，您可以实现命令并让用户决定何时计算结果变化，或者您可以通过验证提供反馈，并且仅在组合有效时评估属性变化。如果有几个相互依赖的属性，我经常使用一个“ChangeInitiator”变量来指示哪个属性发生了变化，这样在计算方法中就可以清楚地知道哪个属性负责变化以及其他哪些属性应该因此而变化。基本上，这与在每个属性 setter 中执行一部分计算相同，但我发现如果关系的不同部分都在一个方法中，它有助于我保持对事物的概览。
在我曾经写过的一个程序中，我定期在后台线程上运行一些计算，所以我会在需要新计算的数据更改时设置一个标志，并根据计时器进行所有更新秒左右...这也可以帮助您更直接地理解逻辑，并且避免为一组相关更改运行多次计算。
关于更改通知，我真的会尽量只将它用于 UI 数据绑定(bind)。
关于c# - 如何避免复杂屏幕上的数据绑定(bind)/事件 hell ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16349380/