最近、ADO.NET Entity Framework で遊んでいますが、開発中のプロジェクトのニーズに合っていることがわかりました。また、その非侵襲的な性質もクールだと思います。
既存のデータベースからデータ モデルを生成した後、生成されたモデルとビジネス ロジックを統合するタスクに直面します。より具体的には、DAL インターフェイスのモック/スタブを介してデータ ストアと対話するクラスの統合テストに慣れています。問題は、ADO.NET Entity Framework を使用してこれを行うことができないことです。ADO.NET Entity Framework が生成するエンティティはインターフェイスのない単純なクラスだからです。
問題は、ADO.NET Entity Framework を使用するアプリケーションの開発にTDD アプローチを適用するにはどうすればよいかということです。これは可能ですか、それとも別の DAL 生成ツールセットに移行する必要がありますか?
Entity Framework に対する大きな批判の 1 つは、テストが本質的に難しいというものでした。
Entity Framework を使用する場合に、これを回避し、データベースにアクセスせずにコードをテストできるようにする方法について説明しているブログ投稿を次に示します。
テスト容易性が大きな懸念事項である場合は、少なくとも Entity Framework 2.0 がリリースされるまでは、NHibernate などの別の ORM フレームワークを検討することをお勧めします。
元の質問には回答がありましたが、何か追加できる気がします。
現在、構築中のイントラネット サイトで Entity Framework 4.0 を使用しています。追加された POCO サポートを使用して、データベース接続なしでビジネス ロジックとコントローラーのすべてをテストできます。
POCO は VS 2010 に含まれる新しい t4 テンプレートから生成できますが、VS 2010 で見つけることができなかったのは、オブジェクト コンテキストを生成するための t4 テンプレートです (オブジェクト コンテキストは基本的に組み込みユニットとして機能します)。 EF の作業の一部であり、EF オブジェクトを POCO にマッピングするために不可欠です)。幸いなことに、 Joachim Lykke Andersenはブログ投稿Entity Framework 4.0 Beta 1 – POCO、ObjectSet、Repository、および UnitOfWorkで、それを生成するための t4 テンプレートを作成しており、非常に役に立ちました。データベース接続なしでテスト可能な EF4 を使用したソリューションを追求する場合は、汎用リポジトリ、作業ユニット ラッパー、および作業ユニット ファクトリを含む、彼のソリューションに似たものを実装することを強くお勧めします。とても役に立ちました。
幸運を祈ります。
私は、Entity Frameworkのバージョン1が設計に対する犯罪であり、それが間違いなく不信任決議を得たことに同意します。EF製品チームは、失敗を認め、コミュニティに設計プロセスを開放することで対応したことを認めています。次のリリースは完璧ではなく、実稼働レベルのアプリケーションで使用する準備ができていない可能性もありますが、悪いデザインが悪いビジネスであることを知っている使用者にとって何が重要かをようやく理解し始めていると思います。そうは言っても…私はまだ疑わしいです。継続的設計時のフィードバックはこれらの人にとっては新しいものであり、私はADO.NETブログで、明るい赤旗を掲げるかなりの数のステートメントを読みました。.NET4.0のリリースでどのようになるかを見ていきます。
彼らはしかし試みているようです：
「エンティティ クラスへの永続化インフラストラクチャの緊密な結合により、自動化されたテストを使用して、ビジネス ロジックで非常にタイトなフィードバック サイクルを効率的に使用する機能が大幅に排除されます。現在の状態では、EF エンティティ クラスをデータベースから独立して効果的に単体テストすることはできません。
ビヘイビアー オブジェクトの自動単体テストの効率は、テスト データのセットアップの仕組みがいかに簡単で、テストをどれだけ迅速に実行できるかに大きく依存します。実際のデータベースを使用すると、テスト データのセットアップがより面倒になり、テストに関係のない関係制約を満たすためにデータが導入され、テストの実行が桁違いに遅くなります。
Entity Framework が懸念事項の分離などの基本的なソフトウェア設計原則に注意を払っていないため、進化的な設計と漸進的な配信を行うチームの能力が損なわれています。」
ここから露骨に盗まれた： http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
特に DAL 生成ツールを検討している場合は、これを TDD と統合するのに苦労するでしょう。私が知っているほとんどの dal 生成ツールは、ビジネス オブジェクトも生成し、それらを DAL に密結合してテストを困難にします。
nHibernate や「永続性の無視」を可能にする Linq to sql などの OR マッピング ツールを見ることができます。ビジネス オブジェクトを自分で定義でき、DAL やその他のインフラストラクチャ コードへのリンクはありません。これにより、ビジネス ロジックをデータベースとは別にテストすることがはるかに簡単になります。また、時々接続されるクライアントのような他のシナリオも有効になることがわかりました。
この答えは「はい、できます」に変更されました。
https://entityinterfacegenerator.codeplex.com/などのカスタマイズされた T4 テンプレートを使用して POCO とインターフェイスを生成し、モッキング オブジェクトを作成して、データベースにアクセスすることなく EF の入出力をテストできます。