c# - 分離のためのLinq-to-Sqlとのインターフェースの使用

Question

モデルクラスをインターフェイスにリファクタリングしています。モデルクラスは、Linq-to-Sqlを使用して自動生成されます。

class FooRepository 
{
    // ...
    public void Add(IFoo foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

InsertOnSubmitメソッドは、IFooではなくFooのインスタンスを取ります。インスタンスを（Foo）にインラインでキャストできますが、これは機能しますが、これを行うためのよりクリーンな方法はありますか？

すでにStructureMapを使用していますが、Addメソッドに属性を追加して、マッピングに基づいてタイプを解決できますか？

または、モデルクラスのメソッドのいずれかをオーバーライドしたり、部分的なイベントを使用してこれを実行したりできますか？

score 1 · Accepted Answer

DLINQモデルをコントローラーから分離するために、私はLINQモデルを渡さない傾向がありますが、DLINQメソッドを呼び出す前にクラスに渡される、コントローラーによって使用される別のモデルがあります。

このようにして、データベースで利用可能な他の多くのプロパティがある場合でも、アプリケーションに必要なプロパティだけをコントローラーに含めることができます。

このように、データベース構造が変更された場合、FooRepositoryなどのDAOクラスのみを変更する必要があり、それ以外はすべて波及効果から保護されます。

このようなことをしたいかどうかはわかりませんが、私が期待するインターフェースを使用するよりも単純な設計になります。

score 0 · Accepted Answer

これが適しているかどうかはわかりませんが、おそらくgenricsを使用することはアイデアかもしれませんか？

class FooRepository<T>
where T: class, IFoo, new() 
{
    // ...
    public void Add(T foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

そして、あなたはこのようなことをすることができます-

Foo bar = new Foo();
FooRepository<Foo> foo = new FooRepository<Foo>();
bar.Add(bar);

またはこれ...

Bar bar = new Bar(); //Bar implements IFoo
FooRepository<Bar> foo = new FooRepository<Bar>();
bar.Add(bar);

このように、FooRepositoryのTは実際にはFoo（またはBar）であり、IFooではないため、キャストは必要ありませんが、where句の制限は、Foo（およびBar）が行うIFooを実装する必要があることを意味します。

2 に答える 2