2009-07-28 10 views
0

私はC#ゲームサーバーでEntity Frameworkを使用してクエリを容易にする方法を検討してきました。私はタイプセーフティの大きなファンです。そして、Entity Frameworkは定型コードのほとんどを自動化するのに素晴らしい仕事をしています。私はいくつかのコンポーネント、すなわちObjectContextを利用する方法についてはあまりよく分かりませんが、エンティティフレームワークとゲームサーバー

サーバーではかなりのスレッドが使用されるため、スレッドの安全性が懸念されます。今私は、クエリを実行するためのカスタムプールを使用しています。多くの詳細に入るがなければ、各クエリはの方法で動作:

  1. グラブDbConnection
  2. グラブDbCommand
  3. DbCommand
  4. を実行し、クエリクラスはパラメータを設定することを許可
  5. DbCommand
  6. がある場合は、クエリクラスがクエリ結果を処理できるようにします。
  7. 無料DbConnection

それは非常に、きれいに高速、かつ安全であるが、問題は、クエリを作成する手間のビットであるということである、と私は私がしたい場合は、手動で生成し、アップデート「コンテナクラス」しなければなりません型の安全性。これが私がEntity Frameworkに目を向ける理由です。

DbCommandだけを使用すると、これらのすべてがうまくいくのですが、DbConnection/Commandがどのオブジェクトまたは何かに対してクエリを実行するかについて心配はありません。

とにかく、制限を課すことなくそれをもっと説明する方法はわかりません。 DbConnection/Commandを使用するたびにクエリを実行したり、保存したり、ObjectContextを破棄したりするたびにクエリを実行するような作業を行うと、データベースを頻繁に更新する必要がないときにオーバーヘッドが増えます。

データベースに対する需要の高いゲームサーバーに対してEntity Frameworkをすぐに最新の状態にするにはどうしたらよいですか?

+0

正確にあなたの質問は何ですか?データベースが頻繁に更新されず、DataContextが巨大なオーバーヘッドを引き起こしてはならない場合。あなたはあなたのdbcommandsとdbconnectionsを処分しますか? –

+0

混乱して申し訳ありません。データベースは頻繁に更新されますが、データは非常に頻繁に読み取られません。 DbCommand/Connectionについては、それを処分したことはありませんでしたが、処分する代わりにプールを使用するように再設計するのは簡単だったからです。私はObjectContextを頻繁に作成/廃棄しても問題ありませんが(コストは安いと仮定していると仮定していますが)、多くのキャッシングoppertunitiesを倒すようです。 – Spodi

答えて

1

エンティティフレームワークとのパフォーマンスの違いに気付くはずの場所は、データの更新(挿入ではありません)です。これは、まずデータをデータベースから読み込み、変更してからデータベースに保存し直す必要があるためです。

オブジェクトコンテキストでは、usingステートメントを使用して、すぐに処理されます。ガベージコレクタがスコープ外のすべてのオブジェクトを処分している間にゲームが一時停止するのは良いことではありません。

主に私がデータをキャッシュすることをお勧めします。例えば、Enterprise Library Cachingアプリケーションブロックを使用してください。

エンティティフレームワークはより生産的なプログラミングモデルを提供し、キャッシングはパフォーマンスを向上させます。

2

まず、あなたがこれを読んで、それを内部化する必要があります。特に注目すべきなの

Performance Considerations for Entity Framework Applications

を:

  1. がいることを正しく再のみ
  2. を照会ノートのマージオプションを設定します。ビューの事前生成は、RelatedEnd.Loadのようなものにのみ役立ち、偶発的なクエリには役立ちません。 CompiledQueryを使用してアドホッククエリを最適化します。クエリーの準備は、複雑なクエリーではかなりのオーバーヘッドになる可能性があります。
  3. ビューをあらかじめ生成しておき、マージオプションを正しく設定すると、オブジェクトコンテキストのインスタンシエートとディスポジションに大きなオーバーヘッドが発生しません。アプリケーションに合った方法で使用してください。そのライフタイムを「時期尚早に最適化」しないでください。
1

あなたはSubsonicをチェックしたいと思うかもしれません - あなたの路地をもう少しアップして、EFほど賢明ではないようにしようとしていて、シンプルさのために一般的にもっとパフォーマンスが良いはずです。同時に、オブジェクト生成の角度も非常によくカバーしているため、書き込みの定型文はほとんどありません。

関連する問題