singleton - シングルトンとしての DDD リポジトリ?

Question

簡単な質問: ドメイン駆動型のデザイン スタイルのリポジトリをシングルトンとして実装することは、良い考えですか、それとも悪い考えですか? なんで？

それとも、依存性インジェクター コンテナーを使用してリポジトリを管理し、それらがシングルトンかどうかを判断する必要がありますか?

私はまだDDD Quicklyを読んでいて、いくつかの良いリポジトリの例を見たいと思っています。

Answer 1

依存性注入コンテナを使用して、リポジトリを作成する方法と場所を決定します。

使用することで

UserRepository.Instance.Find(userId);

あなたはテストへの障壁を作成しています。

リポジトリがコンストラクタ インジェクションを使用してサービスに渡される場合は、それらを簡単にモックに置き換えることもできます。

Answer 2

これを行う方法をいくつか見てきました。

最も一般的な方法は、依存性注入を使用して、リポジトリを使用するオブジェクトにリポジトリを注入することです。通常、これらはプレゼンター クラスまたはコントローラー クラスですが、場合によってはモデルがリポジトリを呼び出します。通常、これは避けたほうがよいでしょう。これを行うために di-container を使用できる場合は、それを使用してください。

リポジトリにシングルトン パターンを実装させることもできます。シングルトンは通常静的メソッドを使用するため、これを回避しようとします。これにより、シングルトンを呼び出すコードのテストがより困難になる可能性があります。このようにする必要がある場合は、シングルトンを呼び出すコードを分離し、「手動の」依存性注入を使用して、シングルトンを呼び出すクラスにシングルトンを注入してください。これにより、他の方法で得られる密結合の一部が取り除かれます。

リポジトリが呼び出されない例をいくつか見てきました。誰かがモデル内のオブジェクト グラフをナビゲートし、ロードされていないオブジェクトを要求すると、モデルはイベントを発生させるだけで、リポジトリはこのイベントに反応します。この方法では、リポジトリへの呼び出しはなく、モデルから完全に切り離されます。私はこのアーキテクチャを自分で使用したことはありませんが、非常にきれいに見えます。

Answer 3

I am not sure about this and I have the same problem. I think that you should make a repository a singleton when the objects that it works with are used often. And that it shouldn't be made a singleton if you use objects that it works with rarely, because the repository would take a lot of memory for objects and maybe it would be called only once and never again during usage of the application. As I said, this may not be correct thinking.

Answer 4

私が理解している限り、ドメインにはリポジトリ インターフェースのみが含まれています。つまり、1 つのインターフェースに対して多くのリポジトリ実装が存在する可能性があります。したがって、インターフェイスで静的メソッドを定義できないため、リポジトリを静的クラスにすることはできません。(注: 一部の言語では、インターフェースで静的メソッドを定義できますが、私にはあまり意味がありません。)

リポジトリは通常、エンティティをデータベースやファイルなどと同期することを目的としているため、依存関係が不安定です。つまり、シングルトンにすることはできず、周囲の依存関係のみを持つことができます。ここにそれに関する記事があります。おもしろいのは、作成者でさえ、ドメインでシングルトンを使用できると言っている点です。

私の理解では、多くのエンティティではなく単一のエンティティのみを持つようにするリポジトリを作成する方がはるかにクリーンです。コードが単一の責任の原則を満たす必要がある場合、それはエンティティではなく、リポジトリの責任です。