11

私は 25 人の開発者のチームで働いています。Sencha の ExtJS MVC パターンを使用します。しかし、彼らの MVC の定義は誤解を招くものだと私たちは考えています。彼らの MVC もアンチパターンと呼ぶかもしれません。

MVC コントローラーの AMAIK は、ビューの名前またはパスしか認識しておらず、ビューの内部構造については認識していません。たとえば、ビューが顧客のリストを単純なドロップダウンまたはオートコンプリートのどちらで表示するかは、コントローラーの責任ではありません。

ただし、Ext JS の MVC では、コントローラーはビューの要素のレンダリングを認識している必要があります。これは、コントローラーがそれらの要素にフックし、それらのイベントをリッスンするためです。これは、ビューの要素が変更された場合 (たとえば、ボタンがリンクになるなど)、コントローラー内の関連するセレクターも変更される必要があることを意味します。言い換えれば、コントローラーはビューの内部構造に密結合されています。

Ext JS の MVC をアンチパターンとして非難するのに、この理由は受け入れられるでしょうか? コントローラーがビューに結合されているというのは正しいですか?

4

6 に答える 6

19

更新 (2015 年 3 月): Ext 5.0 ではViewControllersが導入され、このスレッドで議論されている問題のほとんどに対処する必要があります。利点:

  • ViewController 内のコンポーネント参照に関するスコープの改善/強化
  • アプリケーションのフロー制御ロジックとは別に、ビュー固有のロジックを簡単にカプセル化できます。
  • フレームワークによって管理される ViewController ライフサイクルと、関連付けられているビュー

Ext 5 は引き続き既存のExt.app.Controllerクラスを提供し、下位互換性を維持し、アプリケーションの構造化方法の柔軟性を高めます。

元の答え:

Ext JS の MVC では、コントローラーはビューの要素のレンダリングを認識している必要があります。これは、コントローラーがそれらの要素にフックし、それらのイベントをリッスンするためです。これは、ビューの要素が変更された場合 (たとえば、ボタンがリンクになるなど)、コントローラー内の関連するセレクターも変更される必要があることを意味します。言い換えれば、コントローラーはビューの内部構造に密結合されています。

ほとんどの場合、あなたが引用した正確な理由から、これが最良の選択ではないことに実際に同意します.ExtとTouchに同梱されているほとんどの例が、ビューのカプセル化に違反するセレクターを使用して定義されることが多い参照と制御関数を示しているのは残念です. ただし、これは MVC の要件ではありません。例がどのように実装されているかだけであり、回避するのは簡単です。

ところで、真のアプリケーションコントローラー (制御アプリ フローと共有ビジネス ロジック、ビューから完全に分離する必要があります。これらはあなたが言及しているものです) とビューコントローラー (control/ビューに固有のイベント ロジック (設計により密結合)。後者の例は、ビュー内のウィジェット間を完全に内部的に調整するロジックです。これは一般的な使用例であり、ビュー コントローラーをそのビューに結合することは問題ではありません。これは、ビュー クラスを可能な限りダムに保つコード管理戦略にすぎません。

問題は、ほとんどの文書化された例では、すべてのコントローラーが必要なものを参照するだけであり、それは優れたパターンではないことです。ただし、これは Ext の MVC 実装の要件ではありません。これは、例で使用されている単なる (怠惰な?) 規則です。代わりに、アプリケーション コントローラーに公開する必要があるものに対して、ビュー クラスに独自のカスタム ゲッターとイベントを定義させるのは非常に簡単です (そして、私はそれをお勧めします)。config は単なる省略形です。refsいつでもmyView.getSomeReference()自分のようなものを呼び出すことができ、返されるものをビューに指示させることができます。this.control('some > view > widget')ビューでカスタムイベントを定義するだけでなく、this.control('myevent')そのウィジェットがコントローラーが知る必要があることを行うときに実行します。そのように簡単です。

欠点は、このアプローチにはもう少しコードが必要であり、単純なケース (例など) ではやり過ぎになる可能性があることです。しかし、実際のアプリケーションや共有開発では、それがはるかに優れたアプローチであることに同意します。

そうです、アプリ レベルのコントローラーを内部のビュー コントロールにバインドすること自体がアンチパターンです。しかし、Ext の MVC はそれを必要とせず、自分で行うのを避けるのは非常に簡単です。

于 2013-01-24T08:00:48.117 に答える
1

もちろん、コントローラは何らかの方法でビューにバインドされています。リッスンしたいビューの要素を正確にターゲットにする必要があります。

例: ボタンのクリック、フォーム要素の変更、またはカスタム コンポーネント/イベントをリッスンします。

MVC の目標は、コンポーネントのデカップリングと再利用性であり、Sencha MVC はその点で優れています。@bmoeskau が言うように、MVC パターンを最大限に活用するには、ビュー コントローラー (ビュー/ウィジェット自体の組み込み) とアプリケーション コントローラー (トップ レベルのビュー操作) の分離に注意する必要があります。これはhttp://docs.sencha.com/ext-js/4-1/#!/guide/application_architectureを読んでも明らかではありません。MVC アプローチをリファクタリングし、さまざまなコントローラーを作成し、カスタム コンポーネントを作成し、完全な ExtJS MVC アーキテクチャを採用して活用します。

Sencha アプローチ IMHO にはまだわずかな問題がありrefsます。アプリケーションに同じビューの複数のインスタンスがある場合、MVC システムは実際には機能しません。例: 同じコンポーネントの複数のインスタンスを持つ TabPanel がある場合、参照システムは常に DOM で見つかった最初の要素をターゲットにするため、壊れています...回避策とそれを修正しようとするプロジェクトがありますが、これがうまくいくことを願っていますすぐに対処する。

于 2013-01-25T02:22:15.023 に答える
1

ExtJS 4 の MVC を毎日使用しています。スパゲッティ コードではなく、コンセンの分離を厳密に定義し、保守と拡張が非常に簡単なエレガントな MVC アプリを作成しました。MVC アプローチが提供するものを最大限に活用するには、実装を少し調整する必要があるかもしれません。

于 2013-01-22T12:31:12.747 に答える
0

Sencha Architect を使用してビューを生成し、そのビューから継承して独自のビューを作成すると思います。現在、このビューは、あらゆるイベントに接続し、意味のあるイベントを発生させる責任があります。

これはただの思いつき…

//Designer Generated
Ext.define('MyApp.view.MainView', {
    extend: 'Ext.grid.GridPanel',
    alias: 'widget.mainview',    
    initComponent: function() {
    }
});


//Your View Decorator
Ext.define('MyApp.view.MainView', {
    extend: 'MyApp.view.MainViewEx',
    alias: 'widget.mainviewex',    
    initComponent: function() {
    this.mon(this, 'rowselect', function(){
        this.fireEvent('userselected', arguments);
    }, this);
    }
});
于 2014-02-05T03:58:58.237 に答える