1

2つのモードで動作できるプログラムを作成するプロジェクトがあります。

  1. 内部ユーザーは一元化されたデータベース（SQL Server）にアクセスし、お互いのアイテムを表示/編集できます。

  2. 外部の顧客は、すべての独自のデータをローカルで作成し（SQL Server Compact）、それを電子メールでXMLにパッケージ化して、見積もりを要求します。

問題は、メンテナンスを最小限に抑え、EF機能を最大化するためにこれを行うための最良の方法は何ですか？また、SQL Serverのストアドプロシージャを書き込み操作に使用したいのですが、問題が多すぎる場合、これは最優先事項ではありません。

展開前に別のSSDLを手動で作成することもできますが、これは余分な作業であり、エラーが発生しやすくなります。モデルファーストに移行することもできますが、両方のプロバイダーのデータベースの更新が複雑になると思います。DbContext Generator T4テンプレートを使用してコードファーストの方向に進むことはできますが、変更の追跡やストアドプロシージャのマッピングなど、EFの多くの利点が失われます。また、CFを使用すると、T4テンプレートを大幅に拡張する必要があります。そうでない場合は、別のSSDLを作成する必要があります。

これを簡単にするための記事やツールはありますか？

編集：これを実現するための最良の方法は、Code Firstを使用してモデルを作成し、新しいコードファーストの移行を使用することでした。移行を使用すると、サーバーインスタンス全体の変更スクリプトを生成でき、ローカルCEデータベースに変更全体を適用できます。もう1つの利点は、接続文字列を完全に制御でき、実際に任意のプロバイダーを指すことができることです。

POCOクラスを手動で作成し、構成クラスを作成し（Fluent APIで定義することをお勧めします）、最初の移行クラスに追加（一意のインデックスなど）を追加するのは少し余分な作業ですが、最終的には最小限に抑えられます。全体的に機能します。

後日、ストアドプロシージャの使用法を回避する方法を理解する必要がありますが、それまでにEF 5が利用可能になる可能性があり、問題は解決しました。

4

1 に答える 1

1

また、SQL Server でストアド プロシージャを書き込み操作に使用したいと考えていますが、面倒な場合は最優先事項ではありません。

SQL Compact はストアド プロシージャをサポートしていないため、これを真剣に考えている場合は、マッピングを再利用することはできません。

DbContext Generator T4 テンプレートを使用して Code First の方向に進むこともできますが、そうすると、変更の追跡やストアド プロシージャのマッピングなど、EF の多くの利点が失われます。

ストアド プロシージャ マッピングだけが失われます。変更追跡も同じように機能します。両方のデータベース サーバーに同じマッピング コードを使用することもできますが、SQL サーバーと SQL サーバー コンパクトの間のいくつかの小さな違いに対処する必要があります。

展開前に別の SSDL を手動で作成することもできますが、これは余分な作業であり、エラーが発生しやすくなります。

同じコード ベースで EDMX と大きな SQL Server と SQL Server Compact の両方を使用する場合は、これを行う必要があります。さらに、大規模な SQL Server 実装の機能を、SQL Server Compact でサポートされている機能のみに制限する必要があります。

于 2012-03-18T19:45:17.000 に答える