「ビジネスロジックレイヤー」はどこにMVCアプリケーションに適合しますか？

Question

まず、誰かがデュペを叫ぶ前に、私はそれを簡単なタイトルで要約するのに苦労しました。別のタイトルは、「ドメインモデルとMVCモデルの違いは何ですか？」または「モデルとは何ですか？」

概念的には、モデルがビューとコントローラーが使用するデータであることを理解しています。それを超えて、モデルを構成するものについて多くの異なる意見があるようです。ドメインモデルとは、アプリモデル、VSビューモデル、およびサービスモデルなど。

たとえば、リポジトリパターンについて尋ねた最近の質問で、リポジトリがモデルの一部であるとPoint Blankが言われました。ただし、モデルを永続性モデルとビジネスロジックレイヤーから分離する必要があるという他の意見を読みました。結局のところ、リポジトリパターンは、モデルから具体的な永続性方法を分離することになっていないのではないでしょうか？他の人々は、ドメインモデルとMVCモデルに違いがあると言います。

簡単な例を見てみましょう。 MVCデフォルトプロジェクトに含まれているAccountController。アカウントコードに含まれているデザインが不十分であり、SRPなどに違反しているなど、いくつかの意見を読みました。

モデルからASP.NETサービス（メンバーシッププロバイダー、ロールプロバイダーなど）をどのように分離しますか？それともあなたはまったくしますか？

私が見る方法では、モデルは「純粋」であり、おそらく検証ロジックを使用する必要があります。ただし、ビジネスルール（検証以外）から分離する必要があります。たとえば、新しいアカウントが作成されたときに誰かに電子メールを送らなければならないというビジネスルールがあるとしましょう。私の見解では、それは実際にはモデルに属していません。それで、それはどこに属しますか？

誰かがこの問題に光を当てたいと思っていますか？

Answer 1

私がそれをした方法 - そして私はそれが正しいか間違っていると言っているのではなく、私の見解を持ち、そして私の見解に適用されるモデルを持つことです。このモデルには、データの注釈と検証ルールなど、私の見解に関連するもののみがあります。コントローラーは、モデルを構築するためのロジックのみを収容しています。すべてのビジネスロジックを収容するサービスレイヤーがあります。私のコントローラーは私のサービスレイヤーを呼び出します。それを超えて私のリポジトリレイヤーがあります。

私のドメインオブジェクトは別々に（実際には独自のプロジェクトに）収容されています。独自のデータアノテーションと検証ルールがあります。私のリポジトリは、データベースに保存する前に、ドメイン内のオブジェクトを検証します。私のドメイン内のすべてのオブジェクトは、検証が組み込まれている基本クラスから継承するため、私のリポジトリは一般的であり、すべてを検証します（そして、それが基本クラスから継承する必要があります）。

2つのモデルセットを持つことはコードの複製であり、ある程度だと思うかもしれません。しかし、ドメインオブジェクトがビューに適していない完全に合理的なインスタンスがあります。

適切なケースは、クレジットカードを使用する場合です - 支払いを処理するときはCVVを必要とする必要がありますが、CVVを保存することはできません（50,000ドルの罰金です）。しかし、私はあなたにあなたのクレジットカード、つまり住所、名前、または有効期限の変更を編集できるようにしてほしい。しかし、編集するときに番号やCVVを教えてくれるつもりはありません。また、私はあなたのクレジットカード番号をページにプレーンテキストに載せるつもりはありません。私のドメインには、新しいクレジットカードを保存するために必要なこれらの値があります。なぜなら、あなたは私にそれらを与えているため、私の編集モデルにはカード番号やCVVも含まれていません。

非常に多くのレイヤーのもう1つの利点は、正しくアーキテクチャ化された場合、StructureMapまたは別のIOCコンテナを使用して、アプリケーションに悪影響を与えることなくピースを交換できることです。

私の意見では、コントローラーコードはビューを対象とするコードのみである必要があります。これを示し、それを非表示にします。サービスレイヤーには、アプリのビジネスロジックを収容する必要があります。私はそれをすべて1か所に持っているのが好きなので、ビジネスルールを簡単に変更または調整できます。リポジトリレイヤーは比較的馬鹿げている必要があります - ビジネスロジックがなく、データを照会してドメインオブジェクトを返すだけです。ビューモデルをドメインモデルから分離することにより、カスタム検証ルールに関しては、はるかに柔軟性があります。また、すべてのデータを隠されたフィールドのビューにダンプし、クライアントとサーバーの間で前後に押し込む必要がないことを意味します（またはバックエンドで再構築します）。ビューモデルは、ビューに関連する情報のみを収容します。ビューロジックまたはカウントまたは列挙のブールを使用するようにカスタマイズできます。

<% if (!String.IsNullOrEmpty(Model.SomeObject.SomeProperty) && 
    Model.SomeObject.SomeInt == 3 && ...) { %>

すべてが広がって過剰になっているように見えますが、このように建築されることを目的としています。完璧ですか？あまり。しかし、私はコントローラーからリポジトリを呼び出し、コントローラー、リポジトリ、モデルにビジネスロジックを混合している過去のデザインよりもそれを好みます。

Answer 2

MVC要素が、ビュー（ページ）、コントローラー、サービス、およびデータオブジェクト（モデル）がある従来のWebアプリケーション構造に正確にどのように適合するのか疑問に思いました。あなたが言ったように、それには多くのバージョンがあります。

「貧血ドメインモデル」（疑わしい）-Antiパターンを使用する上記の広く受け入れられているアーキテクチャのために、混乱が存在すると思います。貧血データモデルの「反パターン」についてはあまり詳しく説明しません（あなたは私の努力を見て、物事を説明することができます ここ （Javaベースですが、あらゆる言語に関連します））。しかし、要するに、それは私たちのモデルがデータのみを保持していることを意味し、ビジネスロジックはサービス/マネージャーに配置されます。

しかし、私たちが持っていると仮定しましょう ドメイン駆動型アーキテクチャ, 、そして私たちのドメインオブジェクトは、それらが予想される方法であり、状態とビジネスロジックの両方を持っています。そして、このドメイン駆動型の視点では、物事が配置されます。

• ビューはUIです
• コントローラーはUIの入力を収集し、モデルにメソッドを呼び出し、UIへの応答を送り返します
• モデルは当社のビジネスコンポーネントです - データを保持するだけでなく、ビジネスロジックも持っています。

私はそれがあなたの主な質問に答えると思います。リポジトリレイヤーのように、いくつかのレイヤーを追加すると、事態が複雑になります。多くの場合、モデルに配置されたビジネスロジックによって呼び出されることが示唆されます（したがって、各ドメインオブジェクトにはリポジトリへの参照があります）。私がリンクした私の記事では、これはまったくベストプラクティスではないと主張しています。そして実際、それはサービスレイヤーを持っていることは悪いことではありません。ちなみに、ドメイン駆動型の設計ではサービスレイヤーは除外されませんが、「薄」であると想定されており、ドメインオブジェクトのみを調整します（したがって、ビジネスロジックはありません）。

（良いまたは悪いために）広く採用されている貧血データモデルのパラダイムの場合、モデルはサービスレイヤーとデータオブジェクトの両方になります。

Answer 3

私の意見では、

モデル -

ビジネスロジックを含めるべきではなく、プラグ可能である必要があります（WCFのようなシナリオ）。バインドするために使用されているため、プロパティが必要です。

ビジネスの論理 -

「ドメインサービスレイヤー」に配置する必要があります。これは、完全に個別のレイヤーです。また、ここにもう1つのレイヤー「アプリケーションサービス」が追加されます。

App Servicesは、Domain Services Layerと話し合い、ビジネスロジックを適用し、最後にモデルを返します。

したがって、コントローラーはモデルのアプリケーションサービスを求め、フローは次のようになります。

    Controller->Application Services(using domain services)->Model

Answer 4

MVCパターンとASP.NETフレームワークは、モデルがどうあるべきかを区別しません。

MS自身の例には、モデル内の永続性クラスが含まれます。メンバーシップがモデルにあることについてのあなたの質問。これは依存します。モデルのクラスは何かが所有していますか？誰がログインし、どのデータが表示されるかの間にリンクはありますか？編集可能な権限システムのデータ部分のフィルタリングはありますか？他の誰かがバックエンドサポートのためにそれを見る必要があるように、あなたのドメインのオブジェクト部分を最後に更新または編集した人は誰ですか？

電子メールの例も依存します。特にドメインのイベントやイベントに精通していますか？メールを送信するための別のサービスはありますか？ドメインの電子メール部分を送信する行為は、システムの範囲外でアプリケーションレベルの懸念ですか？ UIは、電子メールが正常に送信されたかどうかを知る必要がありますか？必要なレトリを送信できないメールはありますか？送信された電子メールのコンテンツは、サポートまたはカスタマーサービスの要件のために保存する必要がありますか？

これらのタイプの質問は非常に広くて主観的ですが、私は答えているので、あなたとあなたに投票したすべての人がこれを理解できます。

要件/タイムライン/リソースはすべて、システムのアーキテクチャに流れ込みます。さえ 収益モデル 効果を持つことができます。また、撮影しているパターンを考慮する必要があります。 DDDは、モデルとしての永続性アプリケーションとは大きく異なり、その間のすべてのスロップも特定のアプリで有効です。アプリをテストするために撮影していますか？これらはすべて効果があります。