3

背景:EntityTypeConfiguration - データベースとのマッピングをテストするクリーンメソッドとは何ですか?

私の会社の現在の構造は、「データアクセスオブジェクト」を作成するためのSQLにPlinqo/LINQのを使用して、次に「ビジネスオブジェクト」を構築するためにCodeSmithテンプレートのカスタムセットを使用しています。非常に長いストーリーを短くするために、これらの2つのオブジェクトセットは非常に緊密に結合されており、Linq to SQLでは非常に厄介な回避策につながります。

Plinqoテンプレートは、dbmlを生成した後に、テーブルとクラスの直接1:1マッピングを行います。これにより、データベースが変更された場合に、ビジネスオブジェクト側(またはアプリケーション側)にコンパイル時エラーが発生するといういくつかの慰めがもたらされます。

私は、EF 4.1(コードファースト)が既存のスキーマにマップするメリットをゆっくりと証明しようとしていますが、コード生成のこの「タイプセーフティ」は主要なステークホルダーの心に大きな問題となっています。

問題:

だから、エンティティフレームワーク4.1で、私は既存のデータベースにマッピングするために最初のコードを使用しています。

  • ポコドメインは、各マッピングスキーマへのマッピングが健全であることを確保するためのテストプロジェクトとして示唆している何

ため

  • EntityTypeConfigurationオブジェクト?私は単体テストプロジェクトを作成し、各オブジェクトの取得を行うか、より良い方法がありますか?

    ありがとうございます!

  • 答えて

    1

    CRUD操作を実行する1つの基本汎用統合テストを使用し、導出テストには、エンティティを作成し、各操作の結果を検証するためのメソッドしか含まれていませんでした。各テストメソッドはコミットしていないトランザクションスコープで実行され、テストデータベースはまだ初期状態です。

    これは、リポジトリの使用を開始し、単一のエンティティタイプを扱う代わりに、集約ルートを使用して作業を開始するシナリオでさらに改善できます。そのような場合、集約ルートを操作する正しい統合テストを作成することは非常に便利です。

    +0

    ありがとうございました。私は単体テストの何らかの形が最良のアプローチであると考えました。私は方程式の "データアクセス"(永続性)側の実装を担当しています。私は一般的なリポジトリ(概念の証明)を作成し、ドメインオブジェクトの所有者に集約ルートアプローチを推奨しています。 – junkyspace

    関連する問題