0

ASP.Net MVC ベースのアプリケーションの Entity Framework を評価しようとしています。私の会社は顧客に SQL データベースを出荷しており、顧客がこのデータベースを変更するためのツールを提供しています。彼らは独自のフィールドを追加し、既存のフィールドを変更します (通常はフィールドを大きくします) が、出荷されたフィールドは削除しません。独自のテーブルを追加することもできます。データベースと、各テーブル/フィールドと各フィールドのカスタム検証情報を記述するメタデータ テーブルを変更します。データベースにフィールドを追加し、メタ情報テーブルに入力するためのツールは既にあります。例、「Patient」というテーブルを出荷します。「LastVisitDate」という独自のフィールドをこのテーブルに追加し、このフィールドを FieldDefinitions テーブルにメタ情報 (例: Label = 「Last Visit Date」、

<fields>
    <Patient.LastName>
    <Patient.FirstName>
    <Patient.LastVisitDate> <!-- Added by customer -->
<fields>

基本的に、アプリケーションが起動されるたびに、テーブル構造が何であるかを確認することはできません (そのようなテーブルは何百もありますが、わかりやすくするために省略しています)。

そのようなシナリオでエンティティ フレームワークを使用できますか? これに関する方向性をいただければ幸いです。CRUD 操作を実行するためにオンザフライで SQL クエリを作成する必要はありませんが、EF を使用してこれを達成する方法が明確ではありません。

ありがとう

4

2 に答える 2

0

最大の問題は、EF コンテキストが型を生成する (最初にモデルを作成する) か、指定した型に対して機能する (最初にコードを作成する) ことです。何らかの方法で ObjectContext/DbContext を動的に生成することに成功した場合、それ自体は問題にならないかもしれません。問題は、それが残りのコード ベースを壊してしまうことです。

医療環境、またはユーザー自身がエンティティの属性を継続的に変更する必要がある環境でEAV モデルを目にすることは珍しくありません。それを代替手段として考えたことがあるかどうかわかりませんか？これはクリーンで簡単なソリューションではありませんが、少なくとも継続的なスキーマの変更を必要としないため、現在のソリューションよりも優れている (またはそれほど悪くない) と主張します。

スキーマに不変の部分がある場合 (たくさんあることを願っています)、もちろんそれらに対して EF の使用を開始できます。

于 2012-04-11T20:13:45.323 に答える
0

あなたの要件に基づいて、EFがあなたにとって良いとは思いません。開発者の時間を節約する EF の最大の利点は、厳密に型指定された LINQ クエリを記述し、EF フレームワークを使用してそれらを SQL クエリに変換できることです。

あなたの場合、これを行う簡単な方法はないと思います。したがって、あなたのケースで EF を使用するメリットはありません。

于 2012-04-11T19:41:47.653 に答える