ASP.NETプロジェクトでデータベーススキーマの変更が発生したときにコンパイル時にエラーが発生する方法はありますか？データベーススキーマが変更されたときにコンパイル時エラーが発生する
たとえば、DataSourceにGridViewがバインドされている場合、スキーマの変更が発生した場合にのみ実行時エラーが発生し、コンパイル時エラーは発生しません。 Intellisenseはデータセット、LINQなどを使用しているコードの上でうまく動作しますが、スキーマを変更するとASP.NETページでコンパイル時エラーが発生するようです。
アドバイスはありますか？
データアクセス層の正確性を検証するユニットテストを作成し、すべてのDB関連コードをカバーしていることを確認します。コンパイル時にすべてがキャッチされるわけではありません...
私はこの動作を簡単に達成できると考える方法の1つは、ダイナミックDALにデータバインドすることです。このDAL生成に役立つツールがいくつかありますが、SubSonicをご覧ください。
SubSonicのようなものがあれば、結果のビジネスオブジェクトにバインドできます。これらのビジネスオブジェクトは、データベース内のスキーマ変更の場合に自動的に変更され、バインディングコードが破損し、コンパイル時にエラーが発生します。
更新
ユニットテストを使用するには、アサフの勧告にも良いアイデアです。それはあなたの述べられた問題を解決するものではありませんが、間違いなくその場所にあるべきものであり、これらのタイプの問題にフラグを立てるための素晴らしいツールです。
ビルドタスクとしてセットアップされている場合、DALが再生成されます。そうしないと、DALが保存されません。コード生成なしでデータベーススキーマを変更することはできます。 DALクラスを再生成するのを忘れないでください。 –
私は今どのプロジェクトでも使用していませんが、SubSonicは動的生成を使用しているため、手動で更新する必要はありません。 –
独立した記述からスキーマを作成するために適度なシステム（xmlからC++）を使用します。このシステムでは、コード内で使用するテーブルとカラムの名前も作成します名前が変更されたスキーマに変更があります。これはもともと使用していた名前はもう存在しないため、コンパイラはエラーにフラグを付けます。
おそらく、DAO生成ツールの多くを同様のことを行うように設定できます。
解決策の1つは、データベースをバージョンアップし、アプリケーションビルドを特定のバージョン（多分プロパティファイル内）にマップすることです。あなたのアプリケーションのエントリポイントでは、期待されるバージョンを実際のバージョンと比較し、それに応じてエラーを処理することができます。
ASP.netのMigrations in RailsとJavaのdbdeployがデータベースをバージョン管理するための機能についてはわかりません。しかし、スキーマの変更を増分してバージョン管理し、バージョンテーブルのバージョンを追跡するすべてのDBバージョン管理ツールは、その目的に適しています。
しかし、ビルドプロセスの一環としてスキーマを最新のバージョンにアップグレードして、スキーマを最初に変更する可能性を避けることができます。
+1が常識です。 – Kev