我们的工作中的另一个讨论(这些天来我们已经讨论了很多！)是数据绑定是否是一个坏主意。

我个人认为这是一件坏事吗？

我的理由是三次：

• 它绕过了我精心设计的MVP框架-通过数据绑定，视图与模型进行双向通信。 Ewww。
• 它促进在设计时将视图控件连接到数据字段。以我的经验，这导致重要的代码(将列A绑定到字段X)变得晦涩难懂，并且隐藏在某些设计器文件中。 IMO这段代码应该是明确的，而且是随便的，这样就可以轻松修改和查看正在发生的事情，而不必使用笨拙的设计器界面。
• 与点1有关，这种直接绑定使隔离每个组件(视图，模型，控制器/演示者)和单元测试变得更加困难。

优点是易于设置，并且我们可以利用一些不错的功能(验证等)，这些功能已经为我们完成了管道设置。

但是对我来说，在处理以数据为中心的大型应用程序时，数据绑定变得更加困难。

有什么想法吗？

解决方案

回答

@要点1：如果我们真的想用模式思考，数据绑定引擎不是控制器吗？我们只是不自己编写程序，这是首先使用数据绑定的重点。

回答

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

首先，我同意你的观点！但...

对于企业级应用程序，然后将额外的时间花在系统体系结构，建模和标准上，将为我们提供健壮和可持续的系统。

但是开发将花费更长的时间(或者至少需要更长的时间才能获得初始版本)，并且这可能不适用于每个系统或者系统的每个部分。

有时，我们只需要"快速完成并完成"即可。对于内部应用程序，后台系统和维护应用程序，这些应用程序很少使用或者非常动态(规格经常更改)，因此为此目的构建劳斯莱斯解决方案几乎没有道理。最好让开发人员花一些时间在系统的CRITICAL部分上。

我们要避免/避免的是在系统的"关键任务"区域上使用这些"一键式框架"解决方案，在这些区域中，大事务处理率区域和数据质量和完整性至关重要。花费高质量的时间来减少系统上最频繁使用的区域的毫秒数！

回答

@Timbo：

是的，不是....但是从TDD的角度来看，我想封锁每个控制器，以便我可以独立地对其进行测试。另外，假设我们想通过EditCommand(例如，我们支持Undo)运行每个编辑，这将排除数据绑定。

@Guy：

是的，这正是我的观点。对我来说，数据绑定非常适合非常简单的应用程序，但是我们什么都不做！

回答

Another discussion (we've been having a lot of them these days!) in our work
  is whether data binding is a bad idea or not.
  
  Personally, I think it is a Bad Thing?.

强烈的意见，但是恕我直言，我们会提出所有错误的理由。

It circumvents my well architectured MVP framework - with databinding, the view communicates bi-directionally with a model. Ewww.

我猜这取决于数据绑定的实现。在我的编程生涯的早期，我曾经为MS Access编程做过很多VBA，而Access表单确实具有直接绑定到数据库表/字段的功能。大多数通用语言/框架将数据绑定作为一个单独的组件，不使用这种直接绑定，并且通常被认为是MVC模式意义上的控制器的简单泛型插件。

It promotes hooking up view controls to datafields at design time. In my experience, this leads to vital code (binding column A to Field X) being obscure and hidden away in some designer file. IMO this code should be explicit and in-your-face, so that it is easy to modify and see what is going on, without having to use a clunky designer interface.

我猜我们在谈论WinForms中的绑定吗？我对胜利形式的经验来自很久以前，所以我在这里可能已经过时了。这肯定是一项便利功能，除非我们编写的是非常简单的模态上下文CRUD样式接口，否则我强烈反对。

Relating to Point #1 this direct binding makes it harder to isolate each component (view, model, controller/presenter) and unit-test.

再次-假设视图(WinFoms中的小部件？)与数据绑定意识联系在一起，那么我们是对的。

But for me, databinding becomes much more of a hindrance when dealing with a large data-centric application.

如果将数据绑定实现为独立的组件(例如，Cocoa或者JFace DataBinding或者JGoodies Binding)中的独立组件，则这恰恰相反，该组件充当View和Model之间的控制器，并负责事件处理和转换的所有细节。和验证，那么与做相同事情的自定义控制器代码相比，它更易于使用，更改和替换。

通用数据绑定框架的唯一缺点是，如果绑定已关闭和/或者配置错误，则由于数据绑定代码内部的抽象级别，绑定部分之间的交互非常难以调试。不要犯任何错误！ ;)

回答

我觉得在许多框架中，数据绑定只是以简便的方式做事的借口。就像几乎所有设计师生成的代码一样，它通常会导致太多的代码，这些代码过于复杂且不易调整。我从来没有遇到过不能像我自己编写代码那样好(即使不是更好)做的任务，而且在大多数情况下，我做得还不够快。

回答

我在大型企业系统上与框架结合使用了数据绑定。就我而言，这是CSLA。

它工作得很好，并且极快地使视图起作用。 CSLA内置了许多对数据绑定和验证的支持。

如果它破坏了MVP的作用，那又如何呢？如果它更好，更快，更容易管理。但是，我认为这根本不会破坏这种模式。我们可以在presenter中连接数据绑定，因为它具有对视图和模型的引用。

例如，这就是我们要放置在演示者中的东西，它将填充列表框或者所需的任何控件。

myView.list.datasource = myModel.myCollection;

• 我还要指出，数据绑定不应被视为全有或者全无。当我有一个简单易用的UI要求映射到我的对象模型时，经常使用数据绑定。但是，当需要特殊功能时，我可能会在演示者中放入一些代码以根据需要构建视图，而不是使用数据绑定。

艾伦

回答

我在一些大型系统中使用了数据绑定，发现它工作得很好。

看来我做的事情与我们有些不同...

...我没有数据绑定到模型，而是绑定到一个专用的视图类，该类充当模型的结构和我在屏幕上需要的东西之间的适配器。这包括为组合框和列表视图提供选择之类的东西。

...我从未使用UI设置绑定。取而代之的是，我有一个单一的方法(通常称为Bind()或者BindXYZ())，它将所有内容都放在一个地方。

我的模型仍然不可知，对数据绑定一无所知。我的Presenter坚持为其设计的工作流程坐标；现在，我的视图也是简单的类(易于测试)，它们封装了我的UI行为(启用了按钮X等)，而实际的UI则从侧面简化为简单的帮助器。