Ext JS的MVC是反模式吗？

Question

我在25名开发人员的团队中工作.我们使用Sencha的ExtJS MVC模式.但我们认为他们对MVC的定义具有误导性.也许我们也可以将他们的MVC称为反模式.

MVC控制器中的AMAIK只知道视图的名称或路径,并且不了解视图的内部结构.例如,控制器不负责,视图是将客户列表简化为下拉还是自动完成.

但是,在Ext JS的MVC中,控制器应该知道视图元素的呈现,因为控制器挂钩到这些元素,并监听它们的事件.这意味着如果视图的元素发生变化(例如按钮变为链接),则控制器中的相关选择器也应该更改.换句话说,控制器紧密耦合到视图的内部结构.

谴责Ext JS的MVC作为反模式是否可接受？控制器与视图耦合是否正确？

Answer 1

更新(2015年3月): Ext 5.0引入了ViewControllers,它应解决此线程中讨论的大多数问题.好处:

• ViewController中组件引用的更好/强制范围
• 更容易将视图特定逻辑与应用程序流控制逻辑分开封装
• 由框架管理的ViewController生命周期以及与之关联的视图

Ext 5仍然提供现有的Ext.app.Controller类,以保持向后兼容,并为如何构建应用程序提供更大的灵活性.

原始答案:

在Ext JS的MVC中,控制器应该知道视图元素的呈现,因为控制器挂钩到这些元素,并监听它们的事件.这意味着如果视图的元素发生变化(例如按钮变为链接),则控制器中的相关选择器也应该更改.换句话说,控制器紧密耦合到视图的内部结构.

我实际上同意在大多数情况下,这不是你引用的确切原因的最佳选择,并且很遗憾,Ext和Touch附带的大多数示例都演示了通常使用违反视图封装的选择器定义的引用和控制函数.但是,这不是MVC的要求 - 它只是示例的实现方式,而且很容易避免.

顺便说一下,我认为在真正的应用程序控制器(控制应用程序流和共享业务逻辑,应该完全脱离视图 - 这些是你所指的)和视图控制器(控制/控制器)之间区分控制器样式绝对是有意义的.特定于视图的事件逻辑,通过设计紧密耦合).后者的示例是逻辑,用于在视图内部的窗口小部件之间进行协调,完全在内部到该视图.这是一个常见的用例,将视图控制器耦合到其视图不是问题 - 它只是一种代码管理策略,可以使视图类尽可能保持愚蠢.

问题在于,在大多数记录的示例中,每个控制器只是引用它想要的任何东西,这不是一个很好的模式.但是,这不是Ext的MVC实现的要求 - 它只是在他们的例子中使用的(懒惰？)约定.这很简单(我认为可取)让您的视图类为应该暴露给应用程序控制器的任何东西定义自己的自定义getter和事件.该refs配置仅仅是一个速记-你可以随时拨打像myView.getSomeReference()自己,并允许以规定获取返回的内容.而不是this.control('some > view > widget')仅仅在视图上定义自定义事件,并且this.control('myevent')当该窗口小部件执行控制器需要知道的事情时执行.很简单.

缺点是这种方法需要更多的代码,对于简单的情况(例如示例),它可能是过度的.但我同意对于实际应用程序或任何共享开发,这是一种更好的方法.

所以,是的,将app级控制器绑定到内部视图控件本身就是一种反模式.但Ext的MVC并不需要它,而且避免自己动手也很简单.