0

既存の asp.net アプリケーションを EF4.0/5.0 を使用するように拡張/変換する作業を行っていますが、デザインをレイアウトするためのベスト プラクティスに関するコンセンサスがオンラインで見つからないようです。私の現在のソリューションには 100 万行以上のコードがあり、現在は扱いにくいカスタム データ フレームワークを使用しています。私のデータベースには約 100 のテーブルと約 300 のストアド プロシージャがあり、一部のテーブルは最大 1,000 万行になる場合がありますが、エンティティなどで使用されるのはほんの一部です。典型的なページ読み込みでは、グリッドに表示されているデータベースからエンティティを回復し、ユーザーはそのグリッドを編集してから、最初にエンティティを再度回復してから保存することで保存します。ほとんどのデータはそれほど頻繁には変更されませんが、複数の人が同時に使用している可能性があります。ストアド プロシージャは、テーブルのページング操作などに使用されます。

したがって、私の質問は、今後のプログラミングのニーズに合わせて新しい EF フレームワークを最適にセットアップする方法に関するものです。これまでのところ、次の方法論を見てきました。

  1. 必要なすべてのエンティティ/ストアド プロシージャを含む EDMX で作成します。
  2. EDMX を分割して、それぞれが特定のテーブル/ストアド プロシージャのサブセットを持つようにします。

＃1の利点は、エンティティ間のデータのリンクが簡単になり、エンティティをデータベース全体で効果的にキャッシュできることです。短所は、モデルを最初にロードするコストです。費用ってそんなに高くなるの？モデル全体をインスタンス化して、1 つのエンティティのみを 3 ～ 5 個のクエリに使用する場合、それは大きな問題になりますか?

＃2は＃1の問題のいくつかを解決するようですが、モデル間でエンティティを繰り返したくないため、仕事を完了するために2〜3個のモデルをインスタンス化する必要がある場合があるという問題があります。これは価値がありますか？

これらのモデルの使用方法に関して、私は以下を見てきました。

  1. エンティティを使用する必要があるたびに、それを using ブロックで使用し、ブロックの最後で変更を保存または破棄します。
  2. モデルをセッションに残し、一度だけインスタンス化して、必要なときに再利用します。

これらの両方に利点と問題があることがわかります。主に #1 は、データが常にデータベースと同期することを意味しますが、キャッシュはほとんど存在しません。#2 では、アプリケーションはほぼ db のメモリ内コピーを持つことができますが、非同期になる可能性があります。

私が進めてきた方法は、コンポーネントごとに個別のモデルを作成し、ブロックを使用してすぐに使用および破棄することです。同じ名前空間を使用するモデルもあります。典型的なコード ブロックは次のようになります。

Using(CommonType common = new CommonType()){
Using(mytype type = new mytyp()){
  // execute query on mytype
  // manipulate data using common type

} }

それで、私は何をすべきですか？私はここで私の仮定から完全に外れていますか?

この情報を得るために使用したいくつかのリソース: http://msdn.microsoft.com/en-us/data/hh949853 https://blogs.msdn.com/b/adonet/archive/2008/ 11/24/working-with-large-models-in-entity-framework-part-1.aspx?Redirected=true

4

1 に答える 1

1

遅延読み込みが有効になっていると、統合モデルからエンティティを構築し、必要なビットを使用し、エンティティの使用が終了したら残りを破棄するのに、あまり多くのリソースを必要としないはずです。

バッキング スキーマに比べてエンティティが特に単純な場合は、いくつかの SQL ビューを使用して EF によって作成されたエンティティを単純化するか、デザイナーでエンティティを自分で削除することができます。どちらの方法でも、おそらく必要なパフォーマンスが得られるはずです。

于 2013-03-28T04:21:24.130 に答える