Data binding 数据绑定是个坏主意吗？

在我们的工作中，另一个讨论（这些天我们已经讨论了很多！）是数据绑定是否是一个坏主意

我个人认为这是一件坏事™.

我的理由有三：

它绕过了我精心构建的MVP框架——通过数据绑定，视图与模型双向通信。EWW

它促进在设计时将视图控件连接到数据字段。根据我的经验，这会导致重要代码（将列A绑定到字段X）变得模糊，并隐藏在某个设计器文件中。在我看来，这段代码应该是明确的，并且是面向您的，这样就可以很容易地修改和查看正在发生的事情，而不必使用笨拙的设计器界面

关于第1点，这种直接绑定使得隔离每个组件（视图、模型、控制器/演示者）和单元测试变得更加困难

其优点是它易于设置，并且您可以利用管道已经为您提供的一些不错的功能（验证等）

但对我来说，在处理以数据为中心的大型应用程序时，数据绑定会成为更大的障碍

---

有什么想法吗？

@第1点：如果你真的想以模式思考，那么数据绑定引擎不是控制器吗？您不需要自己编程，这是使用数据绑定的首要目的。

正如我们在英国所说的，“这是课程的马匹”

首先，我同意你的看法！但是

对于企业级应用程序，然后将额外的时间花在系统架构、建模和标准上，将为您提供一个健壮和可持续的系统

但是开发需要更长的时间（或者至少需要更长的时间才能获得初始版本），这可能不适合于每个系统或系统的每个部分

有时候你只需要“尽快完成”。对于很少使用或非常动态（规范经常更改）的内部应用程序、后台系统和维护应用程序，没有理由为此构建劳斯莱斯解决方案。最好让开发人员将时间花在系统的关键部分上

您必须避免/防止的是在系统的关键任务领域使用这些“一键式框架”解决方案，其中大交易率领域以及数据质量和完整性至关重要。在系统中使用最频繁的区域花费高质量的时间减少毫秒数

@Timbo:

是与否。。。。但从TDD的角度来看，我想封锁每个控制器，以便我可以单独测试它。另外，假设我们希望通过EditCommand运行每个编辑（例如，这样我们就支持撤销）——对我来说，这排除了数据绑定

@盖伊：

是的，这正是我的观点。对我来说，数据绑定对于非常简单的应用程序来说是非常好的，但我们不做任何这些

我们工作中的另一个讨论（这些天我们已经有很多了！） 问题在于数据绑定是否是一个坏主意

我个人认为这是一件坏事™.

强烈的意见，但依我看，你提出了所有错误的理由

它绕过了我精心构建的MVP框架——通过数据绑定，视图与模型双向通信。EWW

我想这取决于数据绑定的实现。 在我编程生涯的早期，我曾经为MS Access编程做过很多VBA，Access窗体确实直接绑定到数据库中的表/字段

大多数通用语言/框架都将数据绑定作为一个单独的组件，不使用这种直接绑定，通常被认为是MVC模式意义上控制器的一个简单的通用dropin

它促进在设计时将视图控件连接到数据字段。根据我的经验，这会导致重要代码（将列A绑定到字段X）变得模糊，并隐藏在某个设计器文件中。在我看来，这段代码应该是明确的，并且是面向您的，这样就可以很容易地修改和查看正在发生的事情，而不必使用笨拙的设计器界面

我猜你在谈论WinForms中的绑定

我在win表单方面的经验由来已久，所以我在这里可能已经过时了。 它确实是一个方便的特性，我强烈反对它，除非您编写的是真正简单的模态上下文CRUD样式的接口

关于第1点，这种直接绑定使得隔离每个组件（视图、模型、控制器/演示者）和单元测试变得更加困难

同样-假设视图（WinFoms中的小部件？）与数据绑定感知绑定在一起，您是对的

但对我来说，在处理以数据为中心的大型应用程序时，数据绑定会成为更大的障碍

相反，如果数据绑定是作为一个独立组件实现的（例如Cocoa或JFace DataBinding中的绑定，或JGoodies绑定），它充当视图和模型之间的控制器，负责所有事件处理、转换和验证的细节，那么使用起来就简单多了，更改和替换比您的自定义控制器代码做同样的事情

---

通用数据绑定框架的唯一缺点是，如果绑定关闭和/或配置错误，那么由于数据绑定代码中的抽象级别，绑定块之间的交互很难调试。。。所以你最好不要犯任何错误

我觉得在许多框架中，数据绑定只是一个简单做事的借口。和几乎所有设计师生成的代码一样，它通常会产生太多太复杂且不易调整的代码。我从来没有遇到过一项任务我做得不好（如果不是更好的话），而且在大多数情况下，数据绑定的速度和我自己编写代码的速度一样快。

我使用了databi