在我们的工作中,另一个讨论(我们现在已经有很多这些了!)是数据绑定是否是一个坏主意.
就个人而言,我认为这是一件坏事.
我的理由是三次:
它绕过了我的架构良好的MVP框架 - 通过数据绑定,视图与模型双向通信.EWWW.
它促进了在设计时将视图控件连接到数据域.根据我的经验,这导致重要的代码(将A列绑定到字段X)在某些设计器文件中被隐藏起来并隐藏起来.IMO这段代码应该是明确的并且是面对面的,因此很容易修改并查看正在发生的事情,而不必使用笨重的设计器界面.
与Point#1相关,这种直接绑定使得隔离每个组件(视图,模型,控制器/演示者)和单元测试变得更加困难.
优点是它易于设置,您可以利用已经为您完成的管道附带的一些不错的功能(验证等).
但对我来说,在处理大型以数据为中心的应用程序时,数据绑定变得更加困难.
有什么想法吗？
正如我们在英国所说的那样,"这是课程中的马匹"
首先,我同意你的意见!但...
对于企业级应用程序,将额外时间花在系统架构,建模和标准上将为您提供强大且可持续的系统.
但是开发需要更长的时间(或者至少需要更长时间才能达到初始版本),这可能不适合每个系统或系统的每个部分.
有时你只需要"完成它并快速完成".对于内部应用,后台系统和维护应用很少使用或非常动态(规格经常变化),因此没有理由为此构建劳斯莱斯解决方案.让开发人员花时间在系统的CRITICAL部分上会更好.
您必须避免/阻止的是在系统的MISSION CRITICAL区域使用这些"一键框架"解决方案,其中大事务率区域以及数据质量和完整性至关重要.花费在系统上使用最频繁的区域的毫秒关闭的质量时间!!
| 归档时间： |
|
| 查看次数： |
4704 次 |
| 最近记录： |