Active Directory と SQL データベースの両方に永続的にアクセスする必要がある DDD ベースのシステムを構築しているという独特の状況があります。最初は、これは問題ではありませんでした。これは、次のような作業単位を持つ設計がセットアップされたためです。
public interface IUnitOfWork
{
void BeginTransaction()
void Commit()
}
リポジトリは次のようになります。
public interface IRepository<T>
{
T GetByID()
void Save(T entity)
void Delete(T entity)
}
このセットアップでは、ロードとセーブで両方のデータ ストア間のマッピングが処理されます。これは、自分で作成したためです。作業単位はトランザクションを処理し、リポジトリが永続化のために使用する Linq To SQL データ コンテキストを含みます。Active Directory の部分は、インフラストラクチャに実装されたドメイン サービスによって処理され、各 Save() メソッドのリポジトリによって使用されました。Save() は、すべてのデータベース操作を行うためにデータ コンテキストと対話する役割を果たしました。
現在、これをエンティティ フレームワークに適応させ、POCO を活用しようとしています。理想的には、ドメイン オブジェクトはオブジェクト コンテキストによって追跡されているため、Save() メソッドは必要ありません。作業単位に Save() メソッドを追加して、オブジェクト コンテキストに変更を保存させるだけで済みます。新しいオブジェクトをコンテキストに登録します。新しい提案されたデザインは、次のようになります。
public interface IUnitOfWork
{
void BeginTransaction()
void Save()
void Commit()
}
public interface IRepository<T>
{
T GetByID()
void Add(T entity)
void Delete(T entity)
}
これにより、エンティティ フレームワークに関するデータ アクセスの問題は解決されますが、Active Directory 統合に関する問題は解決されません。以前はリポジトリの Save() メソッドにありましたが、現在はホームがありません。作業単位は、エンティティ フレームワークのデータ コンテキスト以外は何も認識しません。このロジックはどこに行くべきですか?この設計は、エンティティ フレームワークを使用するデータ ストアが 1 つしかない場合にのみ機能すると主張します。この問題に最善のアプローチをする方法はありますか? このロジックをどこに置くべきですか?