私は.NET MVCを使用するのが好きで、過去にかなり使用しました。また、AngularJSを使用してSPAを構築し、最初のページ以外はページをロードしません。多くの場合、この2つをブレンドして使用したいと思います。最初に.NET MVCを使用してアプリケーションをセットアップし、ルーティングサーバー側をセットアップします。次に、各ページをミニSPAとして設定します。これらのページは、クライアント側の機能が多く、かなり複雑になる可能性があります。
私の混乱は、.NET MVCとAngularJSスコープの両方を使用してモデルとビューのバインディングを処理する方法にあります。かみそりのHTMLヘルパーの使用を避けますか? Htmlヘルパーは、背後でマークアップを作成するので、ヘルパーを使用してangularjsタグを追加しようとすると面倒です。たとえば、ng-modelを@ Html.TextBoxFor(x => x.Name)に追加する方法。また、スコープにモデルをロードしていないため、ng-repeatは機能しません。私はまだc#foreachループを使いたいですか?
どこに境界線を引くのですか?誰かが.NET MVCとAngularJSを一緒にうまくプレイできるようにしていますか?そうするためのアーキテクチャ上の提案は何ですか?
クライアント側のレンダリングとサーバー側のレンダリングを自由に組み合わせて使用できますが、ASP.NET MVCヘルパーとAngularJSディレクティブを混在させないことをお勧めします。既にこれらのヘルパーの使用に慣れており、「未加工のhtml」を記述する必要がないため、最初は良い考えのように思えるかもしれませんが、クライアント側のアプリケーションが達成しようとする目的の一部を無効にします。懸念の分離、応答性、データバインディング、およびテスト容易性。
特に、レガシーアプリケーションを変換する場合や、大きなアプリケーションの一部にSPAが不要であるか、SPAなしで最適に提供される場合は、従来の大きなWebアプリケーション内でmini-SPAを作成する場所が間違いなくあります。ただし、特定のページまたはページの一部をクライアントでレンダリングする場合は、完全にバイインして、AngularJSに実行方法がわかっていることを実行させます。
それでは、Productsモデル(の列挙可能なリスト)があり、それをページのリストに表示したいとします。あなたが私が考えることができる3つのオプションがあります:
最後のオプションは醜いです。クライアント側のデータバインディングが必要で、API呼び出しごとに料金を支払わなければならない場合を除いて、それについて本当に正当な理由を考えることはできません。
最初の方法は、クライアントでデータバインディングが必要ない場合(読み取り専用のリスト)、またはSEOが必要な場合に適しています。
2番目は、ほとんどのシナリオで私がそれを行う方法です。理由のためにAngularJSを使用することにしました-任せてください。
MVCヘルパーがあるからといって使用しないでください。 AngularJSは、ほとんど同じことを行う独自のディレクティブを提供します。さらに必要な場合は、独自に作成してください。クライアント側フレームワークの使用の一部は、哲学を理解することです。サーバーは、認証、サーバー検証、APIを介したデータの提供などのサーバーに関連するものを担当し、クライアントはフロントエンドアプリケーションを担当します。心配事は別にしてください。
これは、ルーティング、認証、またはアプリの全体的な構造にASP.NET MVCを使用できないことを意味しません。 AngularJSアプリを取り巻くすべて。ただし、ミニSPAに入ったら、SPAの方法で行います。
これは、ASP.NET MVCをAngularJSと統合するときに使用した哲学です。サーバー側MVCは、最初のページのレンダリングのみを担当し、その後、セミRESTful APIを提供します。 ASP.NET MVCを使用して、URLのルーティング、認証、その他の機能を提供します。しかし、かみそりはほとんどなく、HTMLヘルパーもありません。
私は.NET MVCプログラマではありませんが、PHP、Java、およびAS3プログラミングの多くを行っており、比較的最近ではAngularJSにも切り替えました。
私の一般的な感覚では、バックエンドはRESTfulであり、フロントエンドに実際に触れるべきではなく、フロントエンドはデータのバックエンドにのみ依存するべきであると考えています。サーバー側でビューを作成するほうがよい場合には例外がいくつかあります(たとえば、一貫したエクスポートの場合や、ビューのキャッシュが大幅に役立つ場合など)。
明確な分離線の利点は、チームが独立して作業できるようにすること、または1人で作業している場合は、一度に1つのタスク/問題に集中できるようにすることです(フロントエンドとは別にバックエンドをデバッグできます)。 。さらに、プロジェクトが拡大し、クライアントがネイティブアプリケーションソリューションを必要としている場合でも、RESTful(RESTは純粋に必要ではありませんが、進む方法のように思われます)バックエンドを再利用して、フロントエンドを書き直すことができます。
サーバー上のMVCとクライアント上のAngularJSを組み合わせたアプリを構築しています。
サーバー上:
最も簡単なことは、クライアントにデータサービスを提供するRESTful Web APIの束を構築することでした。また、サーバーで検証を実行して、だまされないようにします(Webページ以外のクライアントを使用してデータを送信します)。また、必要なすべてのライブラリーをロードするために、Webページを(コントローラーと最小限のビューを使用して)組み立てます。ビューから最終的なHTMLへの変更がほとんどないWebページを構築しているので、AngularJSを他のものに置き換えることができるはずです。
クライアント上:
クライアントでは、AngularJSを使用して、Web APIの呼び出しからローカル検証まですべてを処理しました。 Web上の最新のプッシュによってプッシュされている「即時」応答をユーザーに提供します。ページを動的または比較的静的にすることができます。関心事の分離を使用しているアーキテクチャを使用することで、バックエンドをRESTful APIをサポートするものに置き換えることができます。
AngularJSとMVCを組み合わせたアプリを作成しました
ベストプラクティスでは、MVCとangularJSの両方を使用しているときに、サーバーからデータを取得するためにサーバー側でMVC Web APIを使用し、クライアント側でJSONデータをHTMLコントロールにバインドするためにAngularjsフレームワークを使用する必要があるとしています。
確かに...ページを説明するSPAがあり、ページに提供されるデータのみが必要な場合は、必要なデータをフェッチして返すRESTfulサーバーが必要です。これ以上何もない。
2つを混合しようとしている場合は、物事を非常に複雑にする可能性があります。確かにMVCを使用して初期ページを生成するのはまともなアイデアですが、一度実行したら、AngularJS呼び出しでRESTデータを要求する必要があります。テクノロジーは分離しています。