Linq2SQLをテスト容易化のために抽象化する方法

Question

私はデータアクセスのためにLinq2SQLを使用するプロジェクトに取り組んでいます。このプロジェクトは、ASP.NET MVCアプリケーションと8つのクラスライブラリで構成されています。ほとんどのクラスライブラリは、独自のL2Sデータクラスを持っています。

私がやっている作業の一環として、テスト中のさまざまなコンポーネントを取得して、コードベースのクリーンアップを導入しようとしています。現在、静的なクラスとメソッドを大量に使用しています。全体を通して使用されるDataContexts。

L2Sの使用方法をリファクタリングしてコントローラの動作をテストするにはどうすればよいですか？

私は、他のサービスの一部を切り離すためにアプリケーションに依存性注入を導入しましたが、DataContextとそのDataLoadOptionsのインスタンス化を制御したいので、DataContextをコントローラの依存関係プロパティとしてはしたくありません。

私が試したことの1つは、L2Sが生成し、DataContextにインターフェイスを追加した部分クラスを利用していましたが、抽象クラスがクラスライブラリにとどまるのではなく、アプリケーションに邪魔されていました。それは正しいやり方のように感じず、維持するのが苦痛になるでしょう。誰かがこの方法で特別な成功または失敗を経験しましたか？

Answer 1

リポジトリパターンを使用して、DataContextを内部に非表示にします。リポジトリは抽象であるため、Dependency Injectionの原則では本当に良いスイートです。

たとえば、いくつかのリポジトリを定義します。

public interface IUserRepository 
{ 
    User Get(int id); 
    User Save(User user); 
    void Delete(User user); 
} 

実装は今

public class UserRepository : IUserRepository 
{ 
    private MyDataContext _context; 

    UserRepository() 
    { 
     _context = new MyDataContext(); 
    } 

    // ... 

} 

のようなものは、コントローラが唯一のインターフェースに依存しています。

public UserController : Controller 
{ 
    UserController(IUserRepository userRepository) { } 
} 

IUserRepositoryをテストすることができますので、完全にテスト可能です。

Answer 2

this articleは、エンティティフレームワークを使用するテスト可能性を示しますが、ここでは高レベルの概念を適用できます。

"Repository"パターンで "Unit of Work"パターンを使用して、例の概要を説明します。作業単位は、データコンテキストに関する抽象概念であり、特定のコントローラまたは同様のコントローラのセットの作業セットを表します。ユニットには複数のリポジトリを含めることができます。また、リポジトリはIEnumerableまたはIQueryableに基づいているため、LINQ機能を引き続き利用できます。

テスト可能なオプションには、ユニットとリポジトリの模擬テスト、またはテスト目的のメモリ内表現の作成が含まれます。