Question

I work in a team of 25 developers. We use ExtJS MVC pattern of Sencha. But we believe that their definition of MVC is misleading. Maybe we might call their MVC an anti-pattern too.

AMAIK, in MVC controller only knows the name or the path of the view, and has no knowledge on the view’s internal structure. For example, it’s not the responsibility of the controller, whether view renders the list of customers a simple drop down, or an auto-complete.

However, 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.

Is this reason acceptable to denounce Ext JS’s MVC as anti-pattern? Are we right that controllers are coupled to views?

Answer 1

UPDATE (March 2015): Ext 5.0 introduced ViewControllers that should address most of the concerns discussed in this thread. Advantages:

• Better/enforced scope around component references inside the ViewController
• Easier to encapsulate view-specific logic separately from application flow-control logic
• ViewController lifecycle managed by the framework along with the view it’s associated with

Ext 5 still offers the existing Ext.app.Controller class, to keep things backwards-compatible, and to give more flexibility for how to structure your application.

Original answer:

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.

I actually agree that in most cases this is not the best choice for the exact reasons you cite, and it’s unfortunate that most of the examples that ship with Ext and Touch demonstrate refs and control functions that are often defined using selectors that violate view encapsulation. However, this is not a requirement of MVC — it’s just how the examples have been implemented, and it’s easy to avoid.

BTW, I think it definitely can make sense to differentiate controller styles between true application controllers (control app flow and shared business logic, should be totally uncoupled from views — these are what you’re referring to), and view controllers (control/event logic specific to a view, tightly-coupled by design). Example of the latter would be logic to coordinate between widgets within a view, totally internally to that view. This is a common use case, and coupling a view-controller to its view is not an issue — it’s simply a code management strategy to keep the view class as dumb as possible.

The problem is that in most documented examples, every controller simply references whatever it wants to, and that’s not a great pattern. However, this is NOT a requirement of Ext’s MVC implementation — it is simply a (lazy?) convention used in their examples. It’s quite simple (and I would argue advisable) to instead have your view classes define their own custom getters and events for anything that should be exposed to application controllers. The refs config is just a shorthand — you can always call something like myView.getSomeReference() yourself, and allow the view to dictate what gets returned. Instead of this.control('some > view > widget') just define a custom event on the view and do this.control('myevent') when that widget does something the controller needs to know about. Easy as that.

The drawback is that this approach requires a little more code, and for simple cases (like examples) it can be overkill. But I agree that for real applications, or any shared development, it’s a much better approach.

So yes, binding app-level controllers to internal view controls is, in itself, an anti-pattern. But Ext’s MVC does not require it, and it’s very simple to avoid doing it yourself.