實體框架與遊戲服務器

Question

我一直在研究如何在我的C＃遊戲服務器中使用實體框架來簡化查詢。我是類型安全的忠實粉絲，實體框架在自動化大部分樣板代碼方面做得非常出色。雖然我不太清楚如何去利用一些組件，即ObjectContext。

服務器使用了相當多的線程，所以線程安全是一個問題。現在我只是使用自定義池來執行查詢。沒有進入太多細節，每個查詢工作在時尚：

1. 搶DbConnection
2. 搶DbCommand
3. 允許查詢類設置參數
4. 執行DbCommand
5. 允許查詢類來處理查詢結果，如果有的話
6. 免費DbCommand
7. 免費的DbConnection

這是非常乾淨，快速，安全的，但問題是，創建查詢是有點麻煩，我必須手動生成和更新「容器類」如果我想類型安全。這就是我轉向實體框架的原因。

由於不用擔心哪個DbConnection/Command會針對哪個對象或任何對象執行查詢，因此這一切都可以使用DbConnection和DbCommand。

無論如何，我不知道如何解釋它，而不會受到限制。做一些事情，比如每次我通常使用DbConnection/Command執行一個查詢，保存它，並且處理ObjectContext只會增加太多開銷，因爲我不需要頻繁更新數據庫。

您將如何使用實體框架來對遊戲服務器的數據庫要求不高並且不斷更新？

Answer 1

您最有可能注意到與Entity框架的性能差異的地方是數據更新（不插入）。這是因爲必須先從數據庫中讀取數據，然後進行更改，然後再保存回數據庫。

對於對象上下文，我們使用using語句，以便它直接處理。當垃圾收集器運行在超出範圍的所有對象上時，對於遊戲來說暫停並不是件好事。

如果您主要閱讀過，我建議緩存數據，例如使用企業庫緩存應用程序塊。

實體框架將爲您提供更高效的編程模型，而緩存將爲您提供更好的性能。

Answer 2

首先，你需要閱讀這一點，和內在化：

Performance Considerations for Entity Framework Applications

特別需要注意的：

1. 正確設置合併選項重新僅查詢
2. 注意預生成視圖只能幫助像RelatedEnd.Load這樣的事情，而不能用於即席查詢。使用CompiledQuery來優化即席查詢。查詢準備對複雜查詢來說可能是一個很大的開銷，所以儘可能地做到這一點。
3. 如果您預先生成了視圖並且正確設置了合併選項，則實例化和處理對象上下文的開銷並不會很大。以對您的應用有意義的方式使用它;不要「過早地優化」其使用壽命。

Answer 3

您可能想要查看Subsonic - 它比您的衚衕稍微有點多，並且不會像EF那樣聰明，並且通常會因爲簡單性而更具性能。同時它很好地覆蓋了對象生成角度，因此您不會有太多的樣板文字可供編寫。