我们工作中的另一个讨论（这些天我们已经有很多！）是数据绑定是否是一个坏主意。
就个人而言，我认为这是一件坏事™。
我的理由有三个：
它绕过了我架构良好的 MVP 框架——通过数据绑定，视图与模型进行双向通信。万维网。
它促进在设计时将视图控件连接到数据字段。以我的经验，这会导致重要代码（将列 A 绑定到字段 X）在某些设计器文件中变得模糊和隐藏。IMO 这段代码应该是明确的和直接的，这样就可以很容易地修改和查看发生了什么，而不必使用笨重的设计器界面。
与第 1 点相关，这种直接绑定使得隔离每个组件（视图、模型、控制器/演示器）和单元测试变得更加困难。
优点是它易于设置，并且您可以利用已经为您完成的管道附带的一些不错的功能（验证等）。
但对我来说，在处理以数据为中心的大型应用程序时，数据绑定变得更加困难。
有什么想法吗？
正如我们在英国所说，“这是课程的马”
首先，我同意你的看法！但...
对于企业级应用程序，在系统架构、建模和标准上花费额外的时间将为您提供强大且可持续的系统。
但是开发需要更长的时间（或者至少需要更长的时间才能达到初始版本），这可能并不适合每个系统或系统的每个部分。
有时您只需要“完成并快速完成”。对于很少使用或非常动态的内部应用程序、后台系统和维护应用程序（规范经常更改），那么为此构建劳斯莱斯解决方案几乎没有任何理由。最好让开发人员将时间花在系统的关键部分上。
您必须避免/防止的是在系统的关键任务区域使用这些“一键式框架”解决方案，其中大交易率区域以及数据质量和完整性至关重要。花费高质量的时间在系统上使用最频繁的区域减少毫秒！
我们工作中的另一个讨论（这些天我们已经有很多！）是数据绑定是否是一个坏主意。
就个人而言，我认为这是一件坏事™。
强烈的意见，但恕我直言，你提出了所有错误的理由。
它绕过了我架构良好的 MVP 框架——通过数据绑定，视图与模型进行双向通信。万维网。
我想这取决于数据绑定的实现。在我编程生涯的早期，我曾经为 MS Access 编程做过很多 VBA，而 Access 表单确实可以直接绑定到数据库中的表/字段。
大多数通用语言/框架都将数据绑定作为一个单独的组件，不使用这种直接绑定，并且通常被认为是 MVC 模式意义上的控制器的简单通用插件。
它促进在设计时将视图控件连接到数据字段。以我的经验，这会导致重要代码（将列 A 绑定到字段 X）在某些设计器文件中变得模糊和隐藏。IMO 这段代码应该是明确的和直接的，这样就可以很容易地修改和查看发生了什么，而不必使用笨重的设计器界面。
我猜您是在谈论 WinForms 中的绑定？
我对胜利形式的经验来自很久以前，所以我在这里可能已经过时了。它确实是一个方便的特性，我强烈反对它，除非你正在编写非常简单的模态上下文 CRUD 样式接口。
与第 1 点相关，这种直接绑定使得隔离每个组件（视图、模型、控制器/演示器）和单元测试变得更加困难。
再一次 - 假设视图（WinFoms 中的小部件？）与数据绑定意识联系在一起，你是对的。
但对我来说，在处理以数据为中心的大型应用程序时，数据绑定变得更加困难。
恰恰相反——如果数据绑定被实现为一个独立的组件（例如 Cocoa 或 JFace DataBinding 或 JGoodies Binding 中的绑定），它充当 View 和 Model 之间的控制器，负责事件处理的所有细节和转换和验证，那么它比你的自定义控制器代码做同样的事情更容易使用、更改和替换。
通用数据绑定框架的唯一缺点是，如果绑定关闭和/或配置错误，由于数据绑定代码内部的抽象级别，绑定片段之间的交互非常难以调试......所以你最好不要犯任何错误！;)
我在一些相当大的系统中使用了数据绑定，发现它工作得很好。
看来我做的事情和你有点不同......
...我不将数据绑定到模型，而是绑定到专用视图类，该视图类充当模型结构和我在屏幕上需要的内容之间的适配器。这包括为组合框和列表视图提供选择等。
...我从未使用 UI 设置绑定。相反，我有一个方法（通常称为Bind()或BindXYZ()将所有内容连接到一个地方。
我的模型仍然是不可知论者，对数据绑定一无所知；我的 Presenter 坚持其设计的工作流坐标；我的视图现在也是简单的类（易于测试），它们封装了我的 UI 行为（是否启用了按钮 X 等），并且实际的 UI 被降级为一个简单的助手。
在过去的几年里，我对数据绑定有一些不可动摇的认识：
声称数据绑定允许将业务和表示设计为彼此隔离的说法实际上与现实中的实际情况相去甚远。通常，技术中的缺陷会变得很明显，然后您所做的就是将 UI 与特定于 UI 的业务分开，由此产生的分离通常变得比一体式方法更加笨拙。
大多数数据绑定引擎（HTML / WPF / 或其他）都对技术业务模型做出断言，并且由于设计人员通常不具备做出上述断言的能力，因此开发人员最终不得不接触视图。不仅如此，视图不应该对业务模型做出断言——如果有的话，它应该是相反的。
大多数时候，视图模型/控制器/模型/视图都是“耦合的”，然后您真正所做的就是“移动代码”，而不仅仅是简单地使用后面的代码。话虽如此，我确实发现最实用的方法通常是在代码背后谨慎使用数据绑定，而忘记 MVVM/MVC esque 模式。
开发人员经常将视图级别的问题放在视图模型上，然后开始使用数据绑定作为拐杖而不是正确的方法。例如，我见过很多控制 UI 元素可见性的视图模型。
诚然，数据绑定对于“小型系统”很有用。我观察到，随着应用程序的丰富性增长，性能、复杂性和可维护性都会显着降低。
具有数据绑定的内存使用技术通常会成为真正的危险。例如，WPF 使用了很多技巧来避免问题，而且开发人员通常仍然可以自取其辱。除非您使用 Sencha for HTML 之类的东西（我认为），否则即使数据量适中，您也会发现应用程序的内存占用开始受到影响。
我发现在处理分层和情境数据/表示时，数据绑定/UI 模式通常有时会有点崩溃。
我个人对数据绑定的看法是，它是一种容易被滥用的工具，但也有一些引人注目的用途。您可以对任何技术、模式或指南说同样的话。像任何事情一样，太多的事情往往会成为一个问题。我倾向于尝试使用最务实的方法来应对这种情况。在务实的情况下更喜欢一致性，但始终保持务实。换句话说，你不必走上两年开发的道路，然后才得出这样的结论：代码库已经变成了一家满是孤儿小猫的瓷器店里的一只怪异的臭猛犸象。
...
@Point 1：如果您真的想以模式思考，数据绑定引擎不是控制器吗？您只是不自己编程，这就是首先使用数据绑定的全部意义所在。
不会。正确使用DataBinding是一件好事™。
不; 但见#2 和#3。让 Presenter 公开要绑定的属性/明确定义的源。不要暴露模型。没有什么是规避的。
我同意。我不使用任何标准的 ASP.NET 数据源。相反，我使用 GenericDataSourceControl，它连接到返回明确定义的类型的“选择方法”。View 中的 DataSource 消费者只知道这些 Presenter-types；而已。
没有。关于#1。Presenter 公开要绑定的属性/定义明确的源。这些可以在没有正确性视图（单元测试）和应用程序正确性视图（集成测试）的情况下进行测试。
（我的经验是使用 ASP.NET WebForms，这可能与其他数据绑定方案不同。）
@Timbo：
是的，也不是......但从 TDD 的角度来看，我想封锁每个控制器，以便我可以单独测试它。另外，假设我们想通过 EditCommand 运行每个编辑（例如，我们支持 Undo）——对我来说，这排除了数据绑定。
@盖伊：
是的，这正是我的 POV。对我来说，数据绑定非常适合非常简单的应用程序，但我们不做任何这些！
我觉得在很多框架中，数据绑定只是一个简单的做事的借口。与几乎所有设计人员生成的代码一样，它通常会导致代码过多，过于复杂且不易调整。我从来没有遇到过我做不到的任务（如果不是更好的话），而且在大多数情况下，通过数据绑定和自己编写代码一样快。
我在大型企业系统上使用了与框架结合使用的数据绑定。就我而言，它是 CSLA。
它工作得很好，而且让视图工作得非常快。CSLA 有很多内置的数据绑定和验证支持。
如果它打破了 MVP 模式，那又如何？如果它工作得更好更快并且更容易管理。但是，我认为它根本不会破坏模式......您可以在演示器中连接数据绑定，因为它具有对视图和模型的引用。
例如，这是您要放入演示者的内容，它将填充列表框或您想要的任何控件。
myView.list.datasource = myModel.myCollection;
艾伦
我非常同意你的观点，数据绑定有缺点......在我们的应用程序中，如果不小心使用，有时会导致我们的数据一致性不好......
但是可能有一些优雅的方式来处理大型表单的数据绑定？
请在这里给我你的意见： 如何有效地使用绑定框架