MVCのビジネスロジック[終了]
回答:
ビジネスルールはモデルに組み込まれます。
メーリングリストのメールを表示していたとしましょう。ユーザーがいずれかの電子メールの横にある「削除」ボタンをクリックすると、コントローラーはモデルにエントリーNを削除するよう通知し、次にモデルが変更されたビューを通知します。
おそらく、管理者のメールアドレスをリストから削除しないでください。それはビジネスルールです。その知識はモデルに属しています。ビューは最終的にこのルールを何らかの形で表す可能性があります-モデルはビジネスルールの関数である「IsDeletable」プロパティを公開しているため、ビューの削除ボタンは特定のエントリに対して無効になっていますが、ルール自体は含まれていませんビューで。
モデルは、最終的にはデータのゲートキーパーです。UIにまったく触れずにビジネスロジックをテストできるはずです。
要点：
MVCパターンとn層ベースの設計原則を混同していると思います。
MVCアプローチを使用しても、アプリケーションを階層化すべきではありません。
MVCをプレゼンテーション層の拡張のように見れば役立つかもしれません。
非表示コードをMVCパターン内に配置すると、すぐに複雑なデザインになる可能性があります。
したがって、ビジネスロジックを別のビジネスレイヤーに配置することをお勧めします。
これを見てください：多層アーキテクチャに関するウィキペディアの記事
それは言う：
今日、MVCおよび同様のモデルビュープレゼンター（MVP）は、より大きなシステムのプレゼンテーションレイヤーにのみ適用される懸念の分離のデザインパターンです。
とにかく... エンタープライズWebアプリケーションについて話すとき、UIからビジネスロジックレイヤーへの呼び出しは、（プレゼンテーション）コントローラー内に配置する必要があります。
これは、コントローラーが実際に特定のリソースへの呼び出しを処理し、ビジネスロジックを呼び出してデータをクエリし、データ（モデル）を適切なビューにリンクするためです。
泥はあなたにビジネスルールがモデルに入ると言いました。
それも真実ですが、彼は（プレゼンテーション）モデル（MVCの「M」）と層ベースのアプリケーション設計のデータレイヤーモデルを混同しました。
したがって、データベースに関連するビジネスルールをアプリケーションのモデル（データレイヤー）に配置することは有効です。
ただし、これは特定のUIにのみ適用されるため、MVC構造のプレゼンテーションレイヤーのモデルに配置しないでください。
この手法は、ドメイン主導の設計とトランザクションスクリプトベースのアプローチのどちらを使用するかに依存しません。
それを視覚化してみましょう：
プレゼンテーション層：モデル-ビュー-コントローラー
ビジネス層：ドメインロジック-アプリケーションロジック
データレイヤー：データリポジトリ-データアクセスレイヤー
上記のモデルは、MVC、DDD、およびデータベースに依存しないデータレイヤーを使用するアプリケーションがあることを意味します。
これは、大規模なエンタープライズWebアプリケーションを設計するための一般的なアプローチです。
しかし、単純な非DDDビジネスレイヤー（ドメインロジックのないビジネスレイヤー）と、特定のデータベースに直接書き込むシンプルなデータレイヤーを使用するように縮小することもできます。
データレイヤー全体を削除して、ビジネスレイヤーから直接データベースにアクセスすることもできますが、お勧めしません。
それがトリックです...これが役に立てば幸いです...
[注：]現在、アプリケーションには1つ以上の「モデル」があることにも注意する必要があります。通常、アプリケーションの各レイヤーには独自のモデルがあります。プレゼンテーション層のモデルはビュー固有ですが、多くの場合、使用されるコントロールとは無関係です。ビジネスレイヤーは、「ドメインモデル」と呼ばれるモデルを持つこともできます。これは通常、ドメイン主導のアプローチを採用する場合に当てはまります。この「ドメインモデル」には、データとビジネスロジック（プログラムのメインロジック）が含まれており、通常はプレゼンテーションレイヤーから独立しています。プレゼンテーション層は通常、特定の「イベント」（ボタンが押されるなど）でビジネス層を呼び出して、データ層からデータを読み取り、またはデータ層にデータを書き込みます。データレイヤーには、通常、データベースに関連する独自のモデルがある場合もあります。
問題は、これがどのようにMVCコンセプトに適合するかです。
回答->ありません！
まあ-それはちょっとしますが、完全ではありません。
これは、MVCがSmalltalk-80プログラミング言語用に1970年代後半に開発されたアプローチであるためです。当時、GUIやパーソナルコンピュータはごく一般的ではなく、ワールドワイドウェブも発明されていませんでした。今日のプログラミング言語とIDEのほとんどは1990年代に開発されました。当時のコンピューターとユーザーインターフェイスは、1970年代のものとはまったく異なりました。
MVCについて話すときは、そのことを覚えておく必要があります。
Martin FowlerがMVC、MVP、および今日のGUIについて非常に優れた記事を書いています。
私の意見では、ビジネスロジックという用語は正確な定義ではありません。Evansは彼の著書「ドメイン駆動設計」で2種類のビジネスロジックについて語っています。
- ドメインロジック。
- アプリケーションロジック。
この分離は、私の意見では、はるかに明確です。また、ビジネスルールにはさまざまな種類があるという認識とともに、すべてが同じ場所にあるわけではないという認識も生まれます。
ドメインロジックは、実際のドメインに対応するロジックです。したがって、会計アプリケーションを作成する場合、ドメインルールは、アカウント、転記、課税などに関するルールになります。アジャイルソフトウェア計画ツールでは、バックログの速度とストーリーポイントに基づいてリリース日を計算するようなルールになります。等
これらの両方のタイプのアプリケーションでは、CSVインポート/エクスポートが関連する可能性がありますが、CSVインポート/エクスポートのルールは実際のドメインとは関係ありません。この種のロジックはアプリケーションロジックです。
ドメインロジックは、最も確実にモデルレイヤーに入ります。このモデルは、DDDのドメイン層にも対応します。
ただし、アプリケーションロジックは必ずしもモデルレイヤーに配置する必要はありません。これは直接コントローラーに配置することも、それらのルールをホストする別のアプリケーションレイヤーを作成することもできます。この場合の最も論理的なものは、実際のアプリケーションによって異なります。
A1：ビジネスロジックがModel参加しMVCます。の役割Modelは、データとビジネスロジックを含めることです。Controller一方、ユーザー入力を受け取り、何をすべきかを決定する責任があります。
A2：A Business Ruleはの一部ですBusiness Logic。彼らにはhas a関係があります。Business Logic持っていBusiness Rulesます。
見てくださいWikipedia entry for MVC。MVCパターンのフローに言及している概要に移動します。
も見てくださいWikipedia entry for Business Logic。およびBusiness Logicで構成されていると記載されています。Business RulesWorkflow
いくつかの回答が指摘しているように、マルチティアアーキテクチャとMVCアーキテクチャにはいくつかの誤解があると思います。
多層アーキテクチャには、アプリケーションを層/層に分割することが含まれます（例：プレゼンテーション、ビジネスロジック、データアクセス）。
MVCは、アプリケーションのプレゼンテーション層のアーキテクチャスタイルです。重要なアプリケーションの場合、ビジネスロジック/ビジネスルール/データアクセスをモデル、ビュー、またはコントローラーに直接配置しないでください。そのためには、ビジネスロジックをプレゼンテーションレイヤーに配置し、コードの再利用と保守性を低下させることになります。
モデルはビジネスロジックを配置するための非常に合理的な選択ですが、より良い/より保守可能なアプローチは、プレゼンテーションレイヤーをビジネスロジックレイヤーから分離してビジネスロジックレイヤーを作成し、必要に応じてモデルからビジネスロジックレイヤーを呼び出すことです。次に、ビジネスロジックレイヤーがデータアクセスレイヤーを呼び出します。
特に、アプリケーションが複数の層を使用して設計されていない場合は、MVCコンポーネントの1つにビジネスロジックとデータアクセスを混在させるコードが見つかることは珍しくありません。ただし、ほとんどのエンタープライズアプリケーションでは、プレゼンテーションレイヤー内にMVCアーキテクチャを備えた多層アーキテクチャが一般的です。
ビジネスレイヤーをMVCプロジェクトのモデルに配置しても意味がありません。
上司がプレゼンテーション層を別のものに変更することを決定したとしたら、あなたはうんざりするでしょう！ビジネス層は別のアセンブリである必要があります。モデルには、ビューに渡して表示するビジネスレイヤーからのデータが含まれています。次に、たとえば投稿時に、モデルはビジネスレイヤーにあるPersonクラスにバインドし、PersonBusiness.SavePerson（p）;を呼び出します。ここで、pはPersonクラスです。これが私がすることです（BusinessErrorクラスはありませんが、BusinessLayerにも入ります）：
Q1：
ビジネスロジックは、次の2つのカテゴリで検討できます。
電子メールアドレスの制御（一意性、制約など）のようなドメインロジック、請求のための製品の価格の取得、または製品オブジェクトに基づくshoppingCartの合計価格の計算。
学生の登録プロセスの制御など、ビジネスプロセスと呼ばれるより広く複雑なワークフロー（通常、いくつかのステップが含まれ、さまざまなチェックが必要であり、より複雑な制約があります）。
最初のカテゴリはに入りモデルと第二 1はに属しコントローラ。これは、2番目のカテゴリのケースが広範なアプリケーションロジックであり、モデルにそれらを配置すると、モデルの抽象化が混在する可能性があるためです（たとえば、これらの決定を1つのモデルクラスに配置する必要があるかどうかは明確ではありません。両方へ！）。
モデルとコントローラーの具体的な違いについては、この回答を参照してください。このリンクで非常に正確な定義を確認し、このリンクでAndroidの優れた例を確認できます。
重要なのは、上記の「マッド」と「フランク」の両方が「ピート」（ビジネスロジックは、ビジネスロジックの種類に応じてモデルまたはコントローラーに配置できる）と同様に真実である可能性があるということです。
最後に、MVCはコンテキストごとに異なることに注意してください。たとえば、Androidアプリケーションでは、Webベースの定義とは異なるいくつかの代替定義が提案されています（たとえば、この投稿を参照してください）。
Q2：
ビジネスロジックはより一般的であり（上記の「デサイクロン」のように）、それらの間には次の関係があります。
ビジネスルール⊂ビジネスロジック
モデル= CRUDデータベース操作のコード。
コントローラー=ユーザーのアクションに応答し、組織に固有のビジネスルールに従って、データの取得または削除/更新のユーザー要求をモデルに渡します。これらのビジネスルールは、ヘルパークラスに実装することも、複雑すぎない場合はコントローラーアクションで直接実装することもできます。最後に、コントローラはビューにそれ自体を更新するように要求し、新しい表示や「更新、ありがとう」などのメッセージをユーザーにフィードバックします。
ビュー=モデルのクエリに基づいて生成されるUI。
ビジネスルールをどこに適用するかについて、厳格なルールはありません。一部の設計ではモデル化されますが、他の設計ではコントローラーに含まれています。しかし、私はそれらをコントローラーと一緒に保つ方が良いと思います。モデルはデータベース接続のみを考慮します。