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