7

私はタマネギの建築を数日間研究しています。依存性は常に中心に向かうべきであり、これを達成するために依存性注入を使用する方法を理解しています。しかし、まだ理解できない質問がいくつかあります。

  1. モデル（またはエンティティ）はリポジトリインターフェイスまたはサービスインターフェイスを参照できますか？

    例：Orderエンティティには、外部キーではありませんが一意であるプロパティDeliveryCityを通じて確立された関係があります。市をzipで取得するには、電話する必要がありますOder.DeliveryZipICityRepository.FindByZip(zip)

    モデルに次のコードがあります

    class Order
{ 
    . . .

    [Inject]
    public ICityRepository CityRepository { get; set; }

    private City _dCity;

    public City DeliveryCity {
        get {
            if (_dCity == null)
                _dCity = this.CityRepository.FindByZip(this.DeliveryZip);

            return _dCity;
        }
    }
    . . .
}

  2. 上記のコードの問題は何でしょうか？代わりにドメインサービスを使用する必要がありますか？

  3. ドメインサービスの実装は、コア内で定義する必要がありますか、それともインフラストラクチャ層で定義する必要がありますか？

4

3 に答える 3

5

これが、ファクトリがドメインに適合する場所です。OrderFactory は、IOrderRepository への依存や ICityRepository への依存などの依存関係を取ることができます。ファクトリを使用して Order エンティティを作成 (または再構成) する場合、ファクトリは City を検索し、それに応じて Order プロパティを設定できます。または、herzmeister が示唆するように、Lazy を使用して設定し、必要な場合にのみルックアップが実行されるようにします。

于 2012-05-14T13:04:43.937 に答える
5

上記のコードの問題は何でしょうか? 代わりにドメイン サービスを使用する必要がありますか?

ここで考慮すべき 2 つの点:

  1. ICityRepositoryOrder の実際の依存関係ではありません。つまり、Order は他のメソッドにそれを必要としません。真の依存関係は、オブジェクトがそれなしでは機能しないものです。そのため、' ' のようにパラメーターとしてメソッドに渡すことを検討することをお勧めしますGetDeliveryCity(詳細については、こちらを参照してください)。

  2. 郵便番号で都市を見つけることは、注文の責任のようには見えません。注文が凝集するためには、注文関連の機能のみを処理する必要があります。この機能を注文クラスから外したい場合があります。

ドメイン サービスの実装は、コア内で定義する必要がありますか?それともインフラストラクチャ レイヤーで定義する必要がありますか?

これが真のドメイン サービス (アプリケーション サービスではない) の場合は、コア内。

于 2012-05-04T16:45:20.883 に答える
0

  1. どうですか

    private Lazy<City> _dCityLazy;

public City DeliveryCity {
    get {
        return _dCityLazy.Value;
    }
}

    Lazy<City>何らかのメカニズムでどこに注入しますか？

  2. この例では、外部からの注入によって柔軟に決定します。

  3. それは、特定のドメイン サービスが何をするか、どこで使用されるかによって大きく異なります。

于 2012-05-04T17:08:54.283 に答える