web-dev-qa-db-ja.com

ドメインモデルとサービスレイヤーのASP.NET MVCビジネスロジック

ASP.NET MVCプロジェクトでビジネスロジックをどこに配置するかについてしばらく読んでいますが、それでもいくつかのことを明確にすることができません。

1-ドメインモデル。これらは本当に何ですか？私のModelフォルダーには、データベースに対応するクラスの束しかありません。最初にEFコードを使用しています。これらは私のドメインモデルだと思います。

2-Service Layer。 この答え はサービス層を示唆しており、これは完全に理にかなっていると思います。私はこれに行くことにしました。しかし、 Martin Fowlerの "Anemic Domain Models" の記事が私の心を混乱させました。

ドメインモデルにロジックを追加する方法がよくわかりません。

私は多くのビジネスロジック関連の質問を経験してきましたが、それぞれが1または2のどちらかを提案しています。エンティティークラス（私にとってはドメインモデル）にメソッドを追加しても、まったく意味がありません。そして、なぜ2番目のアプローチが悪いと考えられているのですか？

asp.net-mvcbusiness-logicservice-layerdomain-modelanemic-domain-model
35
emre nevayeshirazi

まず、Asp.Net MVCプロジェクトのModelフォルダーをViewModelsに使用する必要があります。これらは、コントローラーがビューに送信するモデルです。それらはビューに対して高度に最適化されている必要があります。つまり、ビューに必要なプロパティのみを意味し、他には何も意味しません。

ドメインモデルはビジネスモデルと同じであり、ビジネスレイヤーに属しています。 Asp.Net MVCプロジェクトのModelフォルダーは、UIレイヤーのモデルです。

2番目のアプローチは、サービス（実際にはビジネス）レイヤーのビジネスロジックが悪いと見なされないことです。これは、データレイヤーとUIレイヤー（3層アーキテクチャ）の間の非常に素晴らしいバッファーです。データレイヤーは、Webサービスまたはデータベースからのデータの取得を処理し、ビジネス/サービスレイヤーは、そのデータをビジネス/ドメインモデルに変換します。また、計算などのビジネスロジックも保持します。

これらのビジネス/ドメインモデルは通常POCOですが、そうである必要はありません。これは私が時々私のビジネスモデルをセットアップする方法です：

public class BusinessObject
{
    private DataObject _dataObject;

    public BusinessObject(DataObject dataObject)
    {
        _dataObject = dataObject;
    }

    public int BusinessId
    {
        get {return _dataObject.Id;}
        set {_dataObject.Id = value;}
    }

    public string Name
    {
        get {return _dataObject.Description;}
        set {_dataObject.Description = value;}
    }
}
26
Martin

私はドメインモデルにビジネスロジックを持たないことを好みます。私は通常、ドメインモデルをPOCOとして保持し、DBテーブル/スキーマを表します。

ビジネスロジックをドメインモデルから遠ざけることで、ドメインモデルを別のプロジェクトでも再利用できます。

これを処理するには、コントローラーとデータアクセスレイヤー/リポジトリレイヤーの間の中間レイヤーを検討します。これをサービス層と呼びます。

13
Shyju

これについてはすでに回答済みですが、モデルを3つのグループに分類します

ViewModels-これらは、サイトのページで必要なデータをモデル化する軽量（多くの場合、poco）クラスです。これらのクラスは、ユーザーに表示されるものの平凡なボイラープレートを処理し、表示するデータが変更されると変更されます。

DomainModels-これらは通常、重いビジネスロジッククラスです。彼らは通常、あなたがやっていることのコアビジネスルールをモデル化します。これらのクラスは非常にまとまりがあり、サイトを特別にする作業の大部分が行われる場所です。これらのモデルは通常重いと言いましたが、実際には、プロジェクトがユーザーからそのデータを取得してデータベースに貼り付けるだけの場合、このクラスは小さなデータマッピングクラスになります。多くの場合、これらのクラスは永続モデルと戻りビューモデルで構成されています。

PersistenceModels-永続化メカニズムのモデルです。私たちのほとんどにとって、これはデータベーステーブルのモデリングを意味しますが、apiリクエストから返される複雑なnosqlドキュメントやjson（またはその他の）データでもかまいません。彼らの責任は、外部データがどのような形をとるかのありふれたボイラープレートを処理することです。

また、プロジェクトにこれらの3つのタイプのモデルがすべて存在する必要があるとは限らないことにも注意してください。時々、あなたのビューモデルはあなたが永続性モデルであるものと一線を画するでしょう。その場合、すべてを2回記述し、ドメインモデルを追加して一方を他方にマッピングするためにクライアントのお金を浪費することになります。あなたは開発者であり、食料品店に行くための空母をいつ作るかを知るのはあなたの仕事です。

10
WhiteleyJ

ドメインモデルは、独自に作業を実行し、その状態と機能を表すプロパティとメソッドを公開できる必要があります。これらは、モデルが機能するために必要な情報の階層へのルート（集約ルート）として機能します。それらは、サービスでのみ使用可能な非表示のままです。

サービスは、データアクセスレイヤーをカプセル化するリポジトリからモデルを取得してメソッド/ビジネスを呼び出すことにより、メッセージパターン（要求/応答）に従ってAPIのセットとしてビジネス/ドメイン機能を外部の世界（Webサービス、UIなど）に公開します。モデルで機能し、最終的にそれらをリポジトリに保存します。

サービスはビジネスオブジェクトのメソッドを繰り返しているように感じることがありますが、実際には実際にはそうではありません。

実際のドメイン駆動設計では、少なくとも3セットのオブジェクトが必要です。ビジネスオブジェクト、ビジネスオブジェクトとサービスのリポジトリ。

コンポーネントの各タイプが異なるチームによって作成されることが常に要件であるかのように考えてください。 1つのチームは、詳細を知らずにサービスを公開する必要があり、他のチームはサービスのロジックを自分で記述する必要はありません。その後、コアモデル自体を掘り下げることなく、サービスを必要とするすべてのユーザーがサービスを利用できます。

2
Panos Roditakis