AngularJSクライアントMVCパターン？
これまで私は主にStruts 2、Spring、JQuery Webアプリケーションを構築するためのテクノロジースタック。ポイントは、前述のスタックはサーバー側のMVCパターンを使用しているということです。 Webブラウザーの主な役割は、要求/応答サイクル（+クライアント側の検証）に限定されていました。データの取得、ビジネスロジック、配線、および検証は、主にサーバー側の責任でした。
AngularJSフレームワークに関して、私が読んだ次の引用に触発されたいくつかの質問があります。
AngularJSチュートリアル から：
Angularアプリの場合、Model-View-Controller（MVC）デザインパターンを使用してコードを分離し、懸念事項を分離することをお勧めします。
Wikipedia Model–view–controllerから：
Model-View-Controller（MVC）は、情報の表現をユーザーとの対話から分離するアーキテクチャです。モデルはアプリケーションデータとビジネスルールで構成され、コントローラーは入力を仲介し、モデルまたはビューのコマンドに変換します
AngularJSはクライアント側のMVCパターンを使用します。だから、何らかの方法でクライアント側にも検証ロジックを含める他のオプションはないと思いますか？
堅牢なAngularJSアプリケーションを作成する最良の方法は何でしょうか？クライアント側のMVCとサーバー側のある種のMC（モデル、コントローラー）？
それは、モデルとコントローラーが1つの方法で複製されていることを意味していますか（クライアント/サーバー）？
私の質問はなんとなく奇妙ですが、その理由は、私が従来のサーバー側のMVCパターンに慣れているからだと思います。既に同じ移行を行った人がいると確信しています。
まったく奇妙な質問ではありません-私はAngularを多くのJava開発者に売り込もうとしています。学んでいた（私はまだ学んでいる、ところで）
説明したように「従来の」Java webappを使用して、Angular化する場合は、まずサーバーを取得してRESTful APIにします。JSPを削除するなどこれは、実際にAngular app-REST APIを正しく取得すること。どのロジックに必要なのかを決定するための鍵です。サーバーに入ったのは純粋なapiであると考え、フロントエンドを持つことをしばらく忘れているです。
その質問は私を本当に助けました-誰かが特定のリソースを保存しようとして、そのリソースに有効なデータがない場合、それらを伝えるフロントエンドはありません-彼らはAPIを直接ヒットしているので、APIはそれを拒否する必要があります。したがって、バックエンドは詳細な検証を行います。これはビジネスロジックにも当てはまります。誰かがAPIをjust使用していると仮定すると、サーバーが何をする必要があるかが明らかになります。
サーバーは（おそらく）json形式（Spring MVC + Jacksonを使用）でデータを販売する必要があるため、モデルをAngularに公開し、データベースと通信する必要があります。
では、Angular側のMVCは何ですか？
- モデル：REST API。からのデータ。APIがJSONを販売している場合、これらのオブジェクトはすでにファーストクラスのjavascriptオブジェクトになります。
- View：HTML、およびDOMを操作する必要がある場合のディレクティブ
- コントローラー：（およびコントローラーからファクタリングしたカスタムサービス..）
- REST APIを照会し、ビューに必要なものを$ scopeに配置します
- サーバーへのコールバックが必要になる可能性のあるイベントに応答するディレクティブのコールバックを提供します。
- 検証：通常、ディレクティブへのコールバック経由。 サーバーに既に設定した検証の一部と重複する可能性が高いが、サーバーがすべてを検証するのをユーザーに待たせたくない-クライアントは、ユーザーに即時のフィードバックを提供するための検証についてsomethingを知っている必要があります。
- ビジネスロジック：検証とほぼ同じストーリー。
しかし、なぜクライアントとサーバーのロジックが重複しているのでしょうか？主に1つのアプリを書いているわけではないため、2つの独立したものを書いています。
- a RESTフロントエンドなしで堅牢で使用可能なAPI
- ユーザーに即座にフィードバックを与える必要があり、必ずしもサーバーを待つ必要のないGUI。
したがって、短い答え-UIがあることを忘れて、REST APIを正しく取得し、Angularがより明確になります。
ここでは、「ビジネスロジック」という用語は少し間違った呼び名だと思います。クライアントサイドアプリの「ビジネス」は、ユーザーインターフェイスを処理するビジネスです。セキュリティルールや独自のロジック、またはその他の機密性の高い知的財産のようなものになることはありません。
だからAngular=分割は（一般的に）：
- コントローラー（コントローラー）：UIの背後にあるデータ（スコープ）を操作します。
- ディレクティブ：スコープを介してコントローラーと通信するようにDOMをセットアップする場合、およびDOMを操作する場合。
- テンプレート（表示）：DOMの要素にディレクティブを割り当てます。
- スコープ（モデルまたはビューモデル）：システムのすべての部分間でデータを運ぶため。
- Services：注入可能、再利用可能なコードのビット。通常、Ajax、Cookie、またはその他のI/Oの処理などの依存関係用。
MVCではなく、ほぼMVVMです。
「ビジネス」ロジックまたはルールについては...セキュリティを必要とするものは、常にサーバーレベルで保護する必要があります。
MVCパターンの一部のバージョンでは、dataおよびmanipulatesのロジックが両方とも「モデル」レイヤーにあることを理解することが重要です（「コントローラー」レイヤーはバインドのみを行います）。ただし、AngularJSでは、データ（$ scope）のみが「モデル」レイヤーに存在し、データ（$ scope）を操作するロジックは「コントローラー」レイヤーに存在します。
ここでの答えに同意します。いくつかのコメント。アプリケーションを作成するとき、まず問題の領域に集中する必要があります。実際のビジネスのソフトウェアモデルを作成します。たとえば、問題のあるドメインがショッピングの場合、モデル化する必要がある要件には次のものが含まれます。
- クレジットカードは有効でなければなりません。
- ブランドXのクレジットカードでお支払いいただくと、10％の割引が適用されます。
- ショップカートには、チェックアウトを実行するために少なくとも1つのアイテムが含まれている必要があります
- ユーザーがアイテムをショップカートに追加できるようにするには、アイテムに在庫が必要です。
これらの要件を実装すると、問題のドメインがモデル化されます。これがビジネスロジックです。
Angularは、フロントエンドフレームワークおよびツールキットです。それはwebフロントエンドです。これをWebフロントエンドに実装すると、モバイルアプリケーションやデスクトップアプリケーションなど、他のフロントエンドまたはインターフェイスからモデルを再利用する機会が失われます。したがって、理想的には、ビジネスロジックの実装をユーザーインターフェイスフレームワークから切り離し、永続的なフレームワークからも切り離す必要があります。次に、ユーザーインターフェイスの問題を処理し、ビジネスロジックオブジェクトと通信するインターフェイスオブジェクトを作成します。これは、Spring MVCコントローラー、および/またはAngularコントローラーまたはサービスです。
サンプルアプリケーション があり、ここで説明した原則に従っています。
@Roy TrueLoveの言葉が大好きです。しかし、これがanglejsを使用する究極の方法であると言えます。もちろん、Angularを最大限に活用したい場合は、この方法でアプリケーションを実行することを学ぶ必要があります。私はいつかそこにいることを祈ります。
一方、学習中、およびクライアント側の主な方法としてangularjsを完全に使用する移行中は、あちこちの小さなミッションで使用することができ、徐々にそれに慣れていくことができます考え。
私は徐々にそれを受け入れ、ゆっくりゆっくりと進むことをお勧めしますが、確かに、私は保証します。
Angularjsは、このアプローチに役立つように設計されています。これは、最大のタスクを実行できるのと同様に最小のタスクでも動作できるためです。たとえば、今回初めてangularを使用したのは、ユーザーがIDを入力している間に名前を表示するためだけでした。
一部の組織は単に新しいテクノロジーに夢中になっているため、この質問も抱えているようです。「クラウドが欲しい、軽量が欲しい」、より軽いフレームワークへの切り替えに値するかどうかを正当化するのは困難です。
私は常にSpring/JBoss seam/JSFを使用し、MVCフレームワーク上でWebアプリケーションを開発しています。ほとんどの場合、Javaスクリプトはプレゼンテーション層の検証用に存在し、メインアクションクラス/エンティティとビジネスロジックはJavaコードに存在します。 Angularの実践では、プレゼンテーションレイヤーの別のレベルを抽象化し、フロントエンドに独自のビューとコントローラーを配置できるMVCの意味を理解し始めました。方法は、プレゼンテーション層に配置することです。
セキュリティの観点から言えば、世界に公開したくないので、重いまたは機密性の高いビジネスルールをサーバー側に常駐させるべきだと思います。ビジネスロジックの開発が不十分な場合、コードの弱点を簡単に見つけて悪用できます。
Angularは小さな店/ SOHOを扱う顧客のようなもので、数人で非常に効率的かつ迅速です。ビジネスに直面している顧客や商品の受け取り/受け取りに適しています。効率的に（REST、JSON）指定されたロールとタスクを持っていますが、一部のワーカーはタスクよりも多くを実行します。また、ショップは通常、重いセキュリティを強調していないため、泥棒や強盗に対して脆弱です。
Spring/Struts 2のようなサーバー側フレームワークについては、異なるレベルの管理を持ち、より大きなビジネス（バッチジョブ、Webサービス、エンタープライズバス）を処理できる現代の企業（CMMレベル5）を想像してください。彼らは顧客を処理しますが、直接ではなく、しばしばブローカーや小売店を経由します。セキュリティに関しては、企業はより堅牢であり、多くの場合、正面玄関の証券、または重要な情報は安全に保護されています（暗号化/サインオン）。
私のアプローチは常にボトムアップのアプローチです。適切に構築された/関連するテーブル、必要に応じてストアドプロシージャを使用してデータベース設計から開始し、Entity Frameworkをソリューションに追加するか、EFがオプションでない場合はADO.Netを使用します。次に、ビジネスロジックとモデルを開発して、データベースにデータを出し入れします。
モデルを確立したら、MVCコントローラーの開発、および/またはWebAPIコントローラーの開発という2つのルートに進むことができます。両方のコントローラーはモデルにアクセスできます。クラスをインスタンス化してメソッドを呼び出すだけです。
これで、MVCコントローラーによって制御されるMVCビュー、またはHTMLページまたはSPA（NodeJSでホストされる単一ページアプリケーション）の完全に別個のセットによって制御されるMVCビューを設定するオプションがあります。
完全に独立したHTMLページのセットでは、Get、Post、Put、およびDeleteメソッドでWebAPIコントローラーを使用し、クライアントを識別するためにトークンを前後に含め、CORS（クロスオリジンリクエスト用）を有効にする必要があります）
MVCビューを使用すると、コントローラー属性やセッションを使用してクライアントを識別でき、CORSを心配する必要がありません。また、必要に応じてビューを厳密に型指定することもできます。残念ながら、一連のUI開発者がいる場合、同じMVCソリューションで作業する必要があります。
どちらの場合でも、AngularJSを使用して、コントローラーとの間でデータをやり取りできます。
私見AngularJSコントローラーの概念は、C＃MVCまたはC＃WebAPIコントローラーとは異なります。 AngularJSコントローラーは、すべてのjavascriptロジックと「ApiFactory」を介したエンドポイントへの呼び出しを格納しますが、C＃コントローラーはUIリクエストを受け入れて応答するサーバー側のエンドポイントにすぎません。