1
私は古いADO.NETコードをLinqにエンティティに移植し始めました。特に有用な関数の1つはObjectContext.TranslateとそのコンパニオンObjectContext.ExecuteStoreQueryです。この関数を使用すると、任意のSQLを使用して、それらを通常の古いデータオブジェクトにラップすることができます。ObjectContext.Translate：列マッピングミスを避ける
ただし、誤って列のマッピングを行うことは簡単です。誤った列名または異なる大文字と小文字の違いにより、.NETプロパティが目的のSQL列に一致しなくなります。これは、DBスキーマが変更されたときに検出するのが特に難しいです。 .NETプロパティがSQL列に対応していない場合、例外はスローされません。エンティティへのLinqはsets the property to the default value（null,0など）になります。この動作は時に便利なことがあり、型に余分なプロパティが含まれている可能性がありますが、特にnullのデフォルト値がその列の有効な値である場合は、バグを隠すことができます。
この動作を変更する方法はありますか、そのような間違いがすぐに分かるように発生時に検出する方法はありますか？
つまり、.NETオブジェクトの形状がSQLクエリの形状と完全に一致している必要がありますか？
右ですが、エンティティフレームワークが列をプロパティにマップするために提供するすばらしいロジックを手動で複製する必要があるため、それはむしろ不自然です。あるいは、実際には、実際には、それぞれのクエリに対して個別にテストを書いて、そのような些細なエラーがないことを確認するだけです。 –
はい、手作業で記述されたクエリを使用しているため、EFがあなたのために処理できるものではないため、これらのテストを手動で記述する必要があります。統合テストは、手書きのクエリを検証するために人々が使用するものです。気に入らない場合は、LINQ-to-entitiesを使用して、これらのエラーをまったく避けてください。 –
それは必要ではありません：自分のコードに検証ステップを追加しました。 DataReader内のすべての列が指定された型のプロパティに対応するかどうかをチェックします。次に、関連するクエリ（私の場合は再び反射で可能です）を列挙し、それらを試してみるだけの簡単なテストが1つあります。 EFにこの検証をさせるだけでなく、データ構造のもう一つの定型表現を維持するよりもはるかに簡単です。 –