MVCのビジネスロジック

Question

質問が2つあります

Q1。 「ビジネスロジック」はMVCパターンのどこに正確に位置していますか？私はモデルとコントローラを混同しています。

Q2。 「ビジネスロジック」は「ビジネスルール」と同じですか？そうでない場合、違いは何ですか？

小さな例で説明できるのは素晴らしいことです。

Answer 1

ビジネスルールがモデルに入ります。

メーリングリストのメールを表示していたとします。ユーザは、電子メールの1つの横にある「削除」ボタンをクリックすると、コントローラはモデルにエントリNを削除するように通知し、モデルが変更されたことをビューに通知する。

おそらく、管理者の電子メールをリストから削除しないでください。知識はモデルに属しているというビジネスルールです。ビューは最終的にこのルールを何らかの形で表すかもしれません - ビジネス・ルールの関数である "IsDeletable"プロパティーを公開しているので、ビュー内の削除ボタンは特定のエントリーでは無効になりますが、ビューに含まれています。

モデルは最終的にデータのゲートキーパーです。 UIに触れることなくビジネスロジックをテストすることができるはずです。

Answer 2

：ビジネスロジックは、のModel部分に行きます。 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であることが言及されている。

Answer 3

ビジネスロジックという用語は、私の意見では正確な定義ではありません。エバンスは彼の著書Domain Driven Designで、ビジネスロジックの2つのタイプについて約束しています。

• ドメインロジック。
• アプリケーションロジック。

この分離は、私の意見ではかなり明確です。ビジネスルールの種類が異なることを認識して、必ずしもすべてが同じ場所に行くわけではないという認識もあります。

ドメインロジックは、実際のドメインに対応するロジックです。したがって、会計アプリケーションを作成する場合、ドメインルールは勘定、転記、課税などに関するルールになります。アジャイルソフトウェア計画ツールでは、ルールは、バックログ内の速度とストーリーポイントに基づいてリリース日を計算し、等

これらのタイプのアプリケーションの両方で、CSVのインポート/エクスポートは関連する可能性がありますが、CSVのインポート/エクスポートのルールは実際のドメインとは関係ありません。この種のロジックはアプリケーションロジックです。

ドメインロジックが最も確実にモデルレイヤーに入ります。このモデルは、DDDのドメイン層にも対応します。

しかし、アプリケーションロジックは必ずしもモデルレイヤーに配置する必要はありません。コントローラに直接配置することもできますし、それらのルールをホストする別のアプリケーション層を作成することもできます。この場合、最も論理的なのは、実際のアプリケーションに依存します。

Answer 4

モデル= CRUDデータベース操作のコード。

コントローラは、ユーザーの操作に応答し、組織固有のビジネスルールに従って、データの取得または削除/更新のユーザー要求をモデルに渡します。これらのビジネスルールは、ヘルパークラスで実装することも、あまり複雑でない場合はコントローラのアクションで直接実装することもできます。コントローラーは最終的にビューを更新して、ユーザーに新しいディスプレイや「更新された感謝」などのメッセージをフィードバックするように指示します。

View =モデルに関するクエリ。

ビジネスルールをどこに適用するかについては、厳格で厳しいルールはありません。いくつかの設計ではモデルに入りますが、他の設計ではコントローラに組み込まれています。しかし、私はそれをコントローラーと一緒に保つ方が良いと思います。モデルにデータベース接続性だけを心配させてください。

Answer 5

すべての主旨：
MVCパターンとn層ベースのデザイン原則が混在していると思います。

MVCアプローチを使用しても、アプリケーションをレイヤーする必要はありません。
MVCがプレゼンテーションレイヤーの拡張のように見える場合は、役立つかもしれません。

プレゼンテーション以外のコードをMVCパターン内に配置すると、すぐに複雑な設計になることがあります。
したがって、私はあなたのビジネスロジックを別のビジネス層にすることをお勧めします。 Wikipedia article about multitier architecture

それは言う：

はちょうどこのを見て

今日、MVCと同様のモデル - ビュー - プレゼンター（MVP）は、のみに適用されます懸念のデザインパターンの分離がありますプレゼンテーション層より大きいシステム。

はとにかく...ビジネスロジック層へのUIからエンタープライズWebアプリケーションの話の呼び出しは、（プレゼンテーション）コントローラ内に配置する必要があります。

コントローラが実際に特定のリソースへの呼び出しを処理し、ビジネスロジックを呼び出してデータを照会し、データ（モデル）を適切なビューにリンクするためです。

ビジネスルールがモデルに組み込まれているとマッド氏に話しました。
これも当てはまりますが、彼は（プレゼンテーション）モデル（MVCの 'M'）と層ベースのアプリケーション設計のデータレイヤーモデルを混在させました。
データベース関連のビジネスのルールをアプリケーションのモデル（データレイヤー）に配置することは有効です。
しかし、これは特定のUIにのみ適用されるため、MVC構造のプレゼンテーションレイヤーのモデルに配置しないでください。

この手法は、ドメイン駆動型設計またはトランザクションスクリプトベースのアプローチを使用する場合とは独立しています。

私はあなたのためにそれを視覚化してみましょう：

---

プレゼンテーション層：モデル - ビュー - コントローラ

---

ビジネス層：ドメインロジック - アプリケーションロジック

---

データ層：データリポジトリ - データアクセス層

---

上記のモデルは、MVC、DDD、およびデータベースに依存しないデータレイヤーを使用するアプリケーションがあることを意味します。
これは、より大きなエンタープライズWebアプリケーションを設計するための一般的なアプローチです。

しかし、単純な非DDDビジネス層（ドメインロジックのないビジネス層）と特定のデータベースに直接書き込むシンプルなデータ層を使用するように縮小することもできます。
データレイヤ全体を削除し、ビジネスレイヤからデータベースに直接アクセスすることもできますが、推奨しません。 ます。また、最近のアプリケーションでただ一つの 『モデル』​​よりもそこにあるという事実を認識しておく必要があります

ザッツトリックが...私は

[注] ...このことができます願っています。 一般に、アプリケーションの各レイヤーには独自のモデルがあります。 プレゼンテーションレイヤーのモデルはビューに固有ですが、使用されるコントロールとはしばしば独立しています。 ビジネス層には、「ドメインモデル」と呼ばれるモデルを含めることもできます。これは通常、ドメイン主導型のアプローチをとることに決めた場合です。 この "ドメインモデル"は、データとビジネスロジック（プログラムのメインロジック）を含み、通常はプレゼンテーションレイヤーから独立しています。 プレゼンテーション層は通常、特定の「イベント」（ボタンが押された状態など）でビジネスレイヤを呼び出して、データレイヤーからデータを読み書きします。 データレイヤーには独自のモデルがあり、通常はデータベースに関連しています。多くの場合、エンティティクラスとデータアクセスオブジェクト（DAO）のセットが含まれています。

質問は次のとおりです。これはMVCの概念にどのように適合していますか？

回答 - >それはありません！
まあまあですが、完全ではありません。
これは、MVCがSmalltalk-80プログラミング言語のために1970年代後半に開発されたアプローチであるためです。当時、GUIやパーソナルコンピュータはまれであり、ワールドワイドウェブは発明されていませんでした。 今日のプログラミング言語とIDEのほとんどは、1990年代に開発されました。 この時点では、コンピュータとユーザーインターフェイスは1970年代とはまったく異なっていました。
MVCについて話すときは、そのことを覚えておく必要があります。 Martin Fowler has written a very good article about MVC, MVP and today's GUIs.

Answer 6

この
は答えた質問ですが、私は私の「1セント」をあげる：

ビジネスルールをモデルに属しています。 「モデル」は常に（論理的または物理的に分離）で構成されています

• プレゼンテーションモデル - ビューでの使用に非常に適しているクラスのセット（それが特定のUI /プレゼンテーションに向かって仕立てています）、
• ドメインモデル - モデルのUI独立部、及び
• リポジトリ - 「モデル」のストレージ認識部。

ビジネスルールはドメインモデル内に存在し、プレゼンテーションに適した形式で「プレゼンテーション」モデルに公開され、「データレイヤー」に重複（または強制）されることがあります。

Answer 7

Q1：のために、製品の価格を取得し、（などの一意性、制約、）電子メールアドレスのコントロールのような

1. ドメインロジック：

   ビジネスロジックは、2つのカテゴリに考えることができます請求書を作成するか、商品オブジェクトに基づいてshoppingCartの総価格を計算します。

2. 生徒の登録プロセスの管理（通常はいくつかのステップがあり、さまざまなチェックが必要であり、より複雑な制約があります）といったビジネスプロセスと呼ばれる、より広範で複雑なワークフロー。

最初カテゴリはモデルに入り、第一方がコントローラに属します。これは、2番目のカテゴリのケースが広範なアプリケーションロジックであり、それらをモデルに入れることは、モデルの抽象化を混在させる可能性があるからです（例えば、これらの決定を1つのモデルクラスに入れなければならないかどうかは、両方へ！）。

モデルとコントローラの特定の区別についてはanswerを参照してください。これは非常に正確な定義についてはlinkです。また、良いAndroidの例ではlinkです。

重要なのは、 "泥"と "フランク"の両方で言及されているメモは、 "Pete"（ビジネスロジックはモデルやコントローラにビジネスのタイプ論理）。

最後に、MVCはコンテキストによって異なります。たとえば、Androidアプリケーションでは、Webベースのものとは異なるいくつかの代替定義が提案されています（たとえばpostを参照）。

---

Q2：

ビジネスロジックは、より一般的であり、（前述の "decyclone" のように）、我々はそれらの間に次のような関係を持っている：

ビジネスルール⊂ビジネスロジック

Answer 8

ビジネスレイヤをMVCプロジェクトのモデルに配置するのは意味がありません。

あなたの上司がプレゼンテーションレイヤーを別のものに変更すると決めたら、あなたは嫌になるでしょう！ビジネスレイヤーは別のアセンブリである必要があります。モデルには、表示するビューに渡すビジネスレイヤからのデータが含まれます。例えば、ポストでは、モデルはビジネス層にあるPersonクラスにバインドし、PersonBusiness.SavePerson（p）を呼び出します。 pはPersonクラスです。私は何をしていますか（BusinessErrorクラスはありませんが、BusinessLayerにも入ります）：

Answer 9

いくつかの誤解があると私は信じています。

多層アーキテクチャは

ティア/層（例えば、プレゼンテーション、ビジネスロジック、データアクセス）にあなたのアプリケーションを壊すMVCは、アプリケーションのプレゼンテーション層のための建築様式である。関係します軽微なアプリケーションでは、ビジネスロジック/ビジネスルール/データアクセスをモデル、ビュー、またはコントローラに直接配置しないでください。これを行うには、ビジネスロジックをプレゼンテーションレイヤーに配置することで、コードの再利用と保守性を減らすことができます。

モデルはビジネスロジックを配置するのに非常に合理的な選択肢ですが、プレゼンテーションレイヤーをビジネスロジックレイヤーから分離してビジネスロジックレイヤーを作成し、ビジネスロジックレイヤーを必要に応じてモデルを作成します。ビジネスロジックレイヤーはデータアクセスレイヤーを呼び出します。

特に、アプリケーションが複数の層を使用して設計されていない場合、MVCコンポーネントの1つにビジネスロジックとデータアクセスを混在させるコードを見つけることは珍しくありません。しかし、ほとんどのエンタープライズアプリケーションでは、プレゼンテーションレイヤー内にMVCアーキテクチャーを備えたマルチティアアーキテクチャーが一般的に存在します。