8

私は Angularjs を使って表面をなぞっていますが、SO の優れた人々を超えて概念的な質問を実行すると思いました。これは経験豊富な開発者からの初心者の質問です。

アプリケーションにはダッシュボードの要件があります...アプリケーションの多くの部分からのものを表示する単一のページ。ユーザーの種類が異なれば、ダッシュボードも異なります。レガシー バックエンドが既にあるため、最初のタスクはダッシュボードを構築して、新しい RESTful サービス レイヤーから多くの情報を表示することです。

これをサポートするために必要なコントローラーについて、概念的にどのように考えるべきか疑問に思っています。

最初の質問は... モデル中心にするかビュー中心にするかです。つまり、「ダッシュボード」という単語が含まれる「ビュー中心」のコントローラーである必要がありますか? または、「タスク」、「連絡先」、「通知」など、それらが表すモデル要素にもっと焦点を当てる必要があります。それとも、ダッシュボード コントローラーがモデル中心のコントローラーで動作する場所の両方が必要ですか?

次の質問は... コントローラーがどのレベルの粒度を表す必要があるかということです。ビュー中心の「ダッシュボード」コントローラーの場合、それらは「ManagerDashboardController」と「WorkerDashboardController」である必要がありますか? モデル中心のコントローラーの場合、「LateTasks」や「OnTimeTasks」などのコントローラーをダッシュ​​ボードのさまざまなセクションに表示する必要があるため、わずかに異なるデータを使用する必要がありますか?

実世界の経験に基づいた具体的なアドバイスや、まだ見つけていない優れたリンクへの参照を探しています。

4

3 に答える 3

7

過去 6 か月間、Angular でビジネス アプリケーションを開発してきた私の見解を以下に示します。

コントローラーの役割

  1. 初期化(初期データの読み込み、オプションの設定)
  2. $scope を介してテンプレートに変数と関数を公開する
  3. $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 の動作を処理する多くの変数と関数がある場合)、それはコントローラーの一部を引き出すことができるという兆候だと思います。ディレクティブに変換して、コントローラーをスリムにします。

于 2013-08-03T08:44:40.123 に答える
3

基本的な考え方

つまり、私は実際にレガシー コード ベースを AngularJs を利用した安らかなベースの Web サービス アーキテクチャに移行する過程にあるのです。

コントローラーは、ビュー (別名 Web ページ) によって消費されるデータの管理を担当します。私の個人的な好みは、コントローラーとそれが提供するビューの間に 1 対 1 の関係があることです。したがって、質問に基づいて、Angularコントローラーはよりビュー中心にする必要があります。とはいえ、私に反対する人がたくさんいることは確かです。

このパターンの拡張性が心配な場合は、ここで説明されているように、ビジネス ロジックとデータ アクセスをAngular Services内に配置する必要があります。これにより、ビジネス ロジック操作の再利用と単体テストの可能性が大幅に向上します。

TLDR;

Angular の仕様は常に変化しており、新しいバージョンごとに新しい標準が存在します。このアプリケーションには、よりビュー中心のアーキテクチャが適しているようです。

この件に関するより完全な読み物については、以下をチェックすることをお勧めします。

于 2013-08-02T21:27:57.667 に答える