通常、リポジトリは、使用することを決定したデータベースの実装の詳細を知っている必要があります。
a）しかし、リポジトリの永続性を無視することの長所/短所は何ですか（つまり、データの保存にどの永続性メディアが使用されているかを認識していません）。私が考えることができる唯一の利点は、どのメディアデータが保持されているかに関係なく、同じリポジトリ実装を使用できることです。
b）リポジトリが永続性を無視するようになっていると仮定すると、リポジトリインターフェイスとその実装の両方がドメインアセンブリ内に存在する必要がありますか？！
ありがとうございました
リポジトリを「永続性を無視する」ようにするのではなく、リポジトリインターフェイスを実装から切り離したい場合があります。たとえば、CustomerRepositoryは、NHibernateCustomerRepositoryとEFCustomerRepositoryの両方で実装できます。このように、実装間の切り替えは、構成を変更するのと同じくらい簡単です（少なくともファンタジー世界では）。これにはいくつかの実際の使用法があります。たとえば、特定のクライアントは独自のソリューションの使用を主張します。
リポジトリ パターンを使用することの要点は、永続化ロジックからドメイン ロジックを分離することです。そのため、異なるデータ ストアで同じドメイン実装を使用できます。したがって、リポジトリの実装がデータベースの実装にある程度依存する必要があるのは当然のことです。
a）主な欠点はパフォーマンスだと思います。リポジトリ ライブラリを抽象化すればするほど、より多くのケースをカバーする、より多くのレベルの抽象化を設計および実装する必要があります。ただし、基盤となるストアの機能をすべて把握していれば、専用のリポジトリの方がパフォーマンスが向上します。
もう 1 つの欠点は、開発と保守のコストです。これらの欠点は、完全に一般的な構造を持つことの利点を上回っていると思います...
b) 小規模なプロジェクトの場合、私の答えは「多分」ですが、他のすべてのプロジェクトの場合は、確実に「いいえ」です。Persistance Ignorance とは何の関係もありません。私が常に従おうとしているベスト プラクティスは、懸念事項の分離です。彼らが別のことをしようとしている場合は、それらを分離します。後で多くの悪夢からあなたを救います。
その他の考え | アイデア、私も喜んで聞きます:)