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