当前位置:  开发笔记 > 编程语言 > 正文

数据绑定是个坏主意吗?

如何解决《数据绑定是个坏主意吗?》经验,为你挑选了1个好方法。

在我们的工作中,另一个讨论(我们现在已经有很多这些了!)是数据绑定是否是一个坏主意.

就个人而言,我认为这是一件坏事.

我的理由是三次:

    它绕过了我的架构良好的MVP框架 - 通过数据绑定,视图与模型双向通信.EWWW.

    它促进了在设计时将视图控件连接到数据域.根据我的经验,这导致重要的代码(将A列绑定到字段X)在某些设计器文件中被隐藏起来并隐藏起来.IMO这段代码应该是明确的并且是面对面的,因此很容易修改并查看正在发生的事情,而不必使用笨重的设计器界面.

    与Point#1相关,这种直接绑定使得隔离每个组件(视图,模型,控制器/演示者)和单元测试变得更加困难.

优点是它易于设置,您可以利用已经为您完成的管道附带的一些不错的功能(验证等).

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

有什么想法吗?



1> Guy..:

正如我们在英国所说的那样,"这是课程中的马匹"

首先,我同意你的意见!但...

对于企业级应用程序,将额外时间花在系统架构,建模和标准上将为您提供强大且可持续的系统.

但是开发需要更长的时间(或者至少需要更长时间才能达到初始版本),这可能不适合每个系统或系统的每个部分.

有时你只需要"完成它并快速完成".对于内部应用,后台系统和维护应用很少使用或非常动态(规格经常变化),因此没有理由为此构建劳斯莱斯解决方案.让开发人员花时间在系统的CRITICAL部分上会更好.

您必须避免/阻止的是在系统的MISSION CRITICAL区域使用这些"一键框架"解决方案,其中大事务率区域以及数据质量和完整性至关重要.花费在系统上使用最频繁的区域的毫秒关闭的质量时间!!

推荐阅读
jerry613
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有