過去 6 か月間、Angular でビジネス アプリケーションを開発してきた私の見解を以下に示します。
コントローラーの役割
- 初期化(初期データの読み込み、オプションの設定)
- $scope を介してテンプレートに変数と関数を公開する
$watch
アプリケーション フロー (状態またはesを変更できる関数の公開による)
従来の MVC フレームワークと同様に、Angular アプリのコントローラーは非常にスリムでなければならないことがわかりました。ビジネス ロジックを controllers に含める必要はほとんどなく、代わりにモデルにカプセル化する必要があります。Miško Hevery のプレゼンテーションの次の行を聞いて、この結論に達しました。「スコープの目的は、モデルを参照することであり、モデルになることではありません。」これは、私がそのプレゼンテーションから得た最も有益で啓発的なセリフでした (ただし、ビデオ全体を見ることをお勧めします)。その行により、コントローラーがほぼ 50% から 70% スリム化されました。
たとえば、私の会社にはOrder
. このビジネス オブジェクトのすべてのプロパティとその動作をカプセル化するモデルを作成し、それらをコントローラーに注入しました。私たちが持っていた 1 つのビジネス ルールは、Booking
(別のビジネス オブジェクト) を に追加する機能でしたOrder
。もともと私のコントローラーには、$scope.addBooking
最初に新しい を作成しBooking
、次に注文を受け取って を実行する関数がありました$scope.order.bookings.push(newBooking)
。代わりに、このビジネス ロジック (関数) をモデルにaddBooking
直接移動し、テンプレートで、コントローラーにコードを 1 行も追加せずに次のようなことを行うことができました。Order
<button ng-click="order.addBooking()">Add Booking</button>
初めてangularを使い始めたときにコントローラーに入力したコードの多くは、取り除かれ、モデル、ディレクティブ、またはサービスのいずれかに配置できることがわかりました(私の場合はほとんどが最初の2つです)。私のコントローラーに残された残りのコードは、ほとんどすべて、上に挙げた上記の 3 つの役割のいずれかに当てはまりました。それは、初期化コード (たとえば、関連するビジネス オブジェクトのデータをフェッチするための AJAX 要求の起動)、オブジェクトのスコープ割り当て、またはアプリケーション フローを処理する関数のスコープ割り当て (たとえば$scope.save
、または$scope.cancel
別のページに戻る可能性がある) のいずれかでした。
コントローラーはモデル中心またはビュー中心のどちらにする必要がありますか?
これは興味深い質問で、これまで考えたこともありませんでした。ビュー中心と聞くと、主にビューと表示方法を処理するコントローラーを思い浮かべます。ビュー中心のコントローラーはおそらくディレクティブに変換できると思われるため、純粋にビュー中心のコントローラーがあってはならないと思います。ビュー中心のコントローラーはDashboard
コントローラーのようなものだとおっしゃっていましたが、これは間違いなく汎用ディレクティブにすることができるもののように聞こえます。ディレクティブはほとんどのビュー ロジックをカプセル化する必要がありますが、コントローラーはモデルをビューに公開して消費することに集中する必要があります (コントローラーの役割に戻ります)。これにより、コントローラーはより頻繁にモデル中心であるべきだと考えています。
私が到達できる唯一の結論は、コントローラーがビュー中心になりすぎた場合 (主にビューと UI の動作を処理する多くの変数と関数がある場合)、それはコントローラーの一部を引き出すことができるという兆候だと思います。ディレクティブに変換して、コントローラーをスリムにします。