1

エンティティを永続性とサービスに依存しないようにしようとしていますが、エンティティのBLOBおよびファイルに対応するプロパティに関しては問題が発生しています。集合体の中に、そのようなエンティティがあるとしましょう（たとえば、基本的なものに保たれています）。

class Attachment
{
    private $_ownerId;
    private $_filename;
    private $_type;
    private $_size;

    public function __construct ($ownerId, $filename, $type, $size)
    {
        $this->_ownerId = $ownerId;
        $this->_filename = $filename;
        $this->_type = $type;
        $this->_size = $size;
    }

    // some getters, etc.
}

私が検討した、または検討しているアプローチ：

  1. のようなメソッドを使用して、サービスインターフェイス、「FileProvider」などを作成しますload (Attachment $file)。その実装者は、ファイルのバイナリを取得して返す方法を知っています。
    • これにより、データアクセスロジック（FileProviderMysql、FileProviderDirectory、FileProviderRemoteFTPなど）の複数の実装が可能になります。
    • これは、エンティティまたは値オブジェクト内に収まらないように見える動作をカプセル化するオブジェクトとしてのサービスクラスのEricEvansの説明に適合しているようです。
    • Evansの本には、サービスクラスが、単純化された意図を明らかにするインターフェイスを使用して、厄介なインターフェイスまたはレガシーインターフェイスへのアクセスをカプセル化する例もあります。
  2. おそらく、エンティティ自体に上記のインターフェイスの実装を注入して、エンティティのコンテンツを他のプロパティと同じ構文でオンザフライで取得できるようにします。
    • このように、アグリゲートのリポジトリ（またはその現在の戦略）は、現在のストレージ実装に対応するサービス実装を注入する機能を持ち、クライアントとアプリケーションサービスがその呼び出しを行うことから解放されます
    • ただし、エンティティがサービスインターフェイスについて本当に「知っている」必要があるかどうかはわかりません。

このシナリオの経験がある人は、私が決断を下すのを手伝ってくれませんか？私がしている仕事が持ちこたえることを確認したいと思います。ありがとうございました...

4

1 に答える 1

2

私はアプローチ1を採用しますが、それはドメインサービスまたはリポジトリのいずれかです。いずれの場合も、添付ファイルに対応するBLOBへのアクセスはカプセル化されます。

BLOBにアクセスする必要があるポイントを考慮することも重要です。ドメイン関連の動作に必要ですか？それとも、インフラストラクチャの問題ですか？

アップデート

アプローチ＃2の利点は、エンティティに関連付けられた動作のカプセル化が増えることです。この場合Attachment、blobをロードするためのサービスを参照している場合、追加の依存関係は必要ないという知識を持って、このエンティティを渡すことができます。これは、より自然なアプローチのようにも思えます。エンティティは他のフィールドへのアクセスを提供するのでAttachment、なぜブロブではないのですか？

ただし、このアプローチにはいくつかの欠点があります。エンティティにサービスまたはリポジトリを参照させることは、責任の交差をもたらす可能性があり、特に依存関係自体が抽象化である場合、エンティティの動作についての推論をより困難にするため、一般的に推奨されません。代わりに、BLOBが必要なユースケースを特定し、それらのユースケースを実装するコード（通常は周囲のアプリケーションサービス）でこのサービスを参照することをお勧めします。

于 2013-01-23T17:34:22.573 に答える