model-view-controller - Ext JS 的 MVC 是反模式吗？

Question

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

AMAIK，在 MVC Controller 中只知道 View 的名称或路径，不知道 View 的内部结构。例如， View 是否将客户列表呈现为简单的下拉列表或自动完成，这不是 Controller 的责任。

然而，在 Ext JS 的 MVC 中， Controller 应该知道 View 元素的渲染，因为 Controller 会钩住这些元素，并监听它们的事件。这意味着如果 View 的一个元素发生了变化(例如一个按钮变成了一个链接)，那么 Controller 中的相关选择器也应该发生变化。换句话说， Controller 与 View 的内部结构紧密耦合。

这个理由谴责 Ext JS 的 MVC 是反模式可以接受吗？我们认为 Controller 与 View 耦合是对的吗？

Answer 1

更新(2015 年 3 月):分机 5.0 引入 ViewControllers这应该解决这个线程中讨论的大部分问题。好处:

ViewController 内部组件引用的更好/强制范围

更容易将特定于 View 的逻辑与应用程序流控制逻辑分开封装

由框架管理的 ViewController 生命周期及其关联的 View

分机 5 仍提供现有的 Ext.app.Controller类，以保持向后兼容，并为如何构建应用程序提供更大的灵 active 。

原答案:

in Ext JS's MVC, controller should know the rendering of view's elements, because controller hooks into those elements, and listens to their events. This means that if an element of the view change (for example a button become a link), then the relevant selector in the controller should change too. In other words, controller is tightly-coupled to the internal structure of the view.

我实际上同意，在大多数情况下，由于您引用的确切原因，这不是最佳选择，而且不幸的是，Ext 和 Touch 附带的大多数示例都演示了通常使用违反 View 封装的选择器定义的 refs 和控制功能。然而，这不是 MVC 的要求——这只是示例的实现方式，很容易避免。

顺便说一句，我认为区分真正的 Controller 样式绝对是有意义的 申请 Controller (控制应用程序流和共享业务逻辑，应该与 View 完全分离——这些就是您所指的)，和 查看 Controller (特定于 View 的控制/事件逻辑，通过设计紧密耦合)。后者的示例是在 View 内的小部件之间进行协调的逻辑，完全在该 View 内部。这是一个常见的用例，将 View Controller 耦合到它的 View 不是问题——它只是一种代码管理策略，可以使 View 类尽可能地哑。

问题在于，在大多数记录的示例中，每个 Controller 都只是引用它想要的任何内容，这不是一个很好的模式。然而，这不是 Ext 的 MVC 实现的要求——它只是他们的示例中使用的(惰性？)约定。让您的 View 类为应该暴露给应用程序 Controller 的任何内容定义自己的自定义 getter 和事件非常简单(我认为这是可取的)。 refs config 只是一个简写——你总是可以调用像 myView.getSomeReference() 这样的东西。自己，并允许 View 决定返回的内容。而不是 this.control('some > view > widget')只需在 View 上定义一个自定义事件并执行 this.control('myevent')当该小部件执行 Controller 需要了解的操作时。就这么简单。

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

所以是的，将应用程序级 Controller 绑定(bind)到内部 View 控件本身就是一种反模式。但是Ext的MVC不需要它，避免自己做也很简单。