0

私のプロジェクトの 1 つで、n 層アーキテクチャを使用しています。

DAL (Repository Pattern) <-> BLL (POCO Services) <-> Web UI (ASP.NET MVC)

汎用リポジトリを作成しましたが、DAL レイヤーではすべて問題ありません。

ビジネスロジックレイヤーには、次のように動作するサービスメソッドがあります（ピザのために使用するのが大好きな例:)

myOven.Bake(myPizza);

myPizzaただし、次のように、オブジェクトの内部にある特定の情報が必要です。

myPizza.GetBakeTime();

私は知っています、私は次のようなものを使うことができます:

myOven.GetBakeTimeFor(myPizza);

myOvenこれはそれを計算できますが、その特定のロジックをオブジェクト (ここではサービス層)に入れたくありません。代わりにmyPizza、

public partial class Pizza
{
    public double GetBakeTime()
    {
        // calculate Bake Time and return, based on other variables
    }
}

つまり、ORM で生成されたクラスを拡張して、この機能を提供するということです。

私の質問: これは理論的には可能ですが、 と の両方Domain LogicをBusiness Logic同じクラスで使用する場合に考慮すべき考慮事項はありますか?

4

1 に答える 1

2

ドメイン層は、ビジネス関連の機能のみを処理する必要があります。リポジトリは、データの永続性を処理します。この 2 つは目的が異なるため、混同してはなりません。

また、ドメイン層はほぼビジネス層です。ベイク時間のみが必要なこの特定の例では、特殊なクエリ リポジトリは、ドメインを使用せずに答えを知る必要があります (事前に計算されているため)。ベーキングの残り時間を知りたい場合は、サービス (ドメインの一部) がオーブンとピザのエンティティを使用して値を取得できます。

ただし、これはすでに具体的すぎて、解決したい実際の問題にはまったく適していない可能性があります。

于 2012-06-15T10:20:18.837 に答える