リポジトリ インターフェイスを実装する 2 つの異なるモデルに 2 つのデータ コレクションがあります。それらの 1 つは、リポジトリ モデルに最適なフラット リストにあります。もう 1 つのデータ モデルはツリー構造でフォーマットされており、私が構築したリポジトリ インターフェイスの実装は非常に怪しいものに見えます。2 番目のデータ モデルをフラット化し、親への参照のみを使用することもできますが、現在、アプリケーションはデータをツリー構造として取得できるという大きな利点を持っています。
誰かがツリー構造のデータ モデルを使用してリポジトリ パターンを実装した経験があるかどうかを知りたいです。現在、私のGet(Func<T, bool> predicate)
メソッドでは、再帰メソッドでリストをフラット化し、LINQ クエリでオブジェクトを返しますが、この実装は少しコストがかかるように感じます。
これを実装する方法についてのヒントをいただければ幸いです。
実装の愚かさを説明するのに役立つ場合は、述語メソッドによる取得の実装を次に示します。
protected virtual IEnumerable<T> Get(Func<T, bool> predicate)
{
var objects = GetAll<T>();
return objects.Where(predicate);
}
編集: いくつかのコード
private IEnumerable<TreeData> GetRecursiveObjects(TreeData object)
{
var allChildren = new List<TreeData>();
allChildren.AddRange(object.Children);
foreach (var child in object.Children)
{
allChildren.AddRange(GetRecursiveObjects(child).ToArray());
}
return allChildren;
}
protected virtual IEnumerable<T> GetAll<T>()
{
var objects = new List<T>();
objects.AddRange(Objects);
foreach (var object in Objects)
{
objects.AddRange(GetRecursiveObjects(object));
}
return objects.OfType<T>();
}
2番目の編集:
また、リポジトリに要素を追加するための優れた戦略についても少し混乱しています。コードを使用して親要素の子への追加を処理する必要がありますか、それともリポジトリが要素とその親への参照の両方を取得し、追加操作全体を処理する必要がありますか?
tl;dr
ツリー構造のデータを使用してリポジトリ インターフェイスを実装しようとするのは正気ではありませんか?