实体框架与游戏服务器

Question

我一直在研究在我的C＃游戏服务器中使用Entity Framework来简化查询。我是类型安全的忠实粉丝，实体框架在自动化大多数样板代码方面做得很好。虽然我不太清楚如何利用某些组件，即ObjectContext。

服务器使用了相当多的线程，因此线程安全是一个问题。现在我只使用自定义池来执行查询。没有详细说明，每个查询都以下列方式工作：

1. 抓住DbConnection
2. 抓住DbCommand
3. 允许查询类设置参数
4. 执行DbCommand
5. 允许查询类处理查询结果（如果有）
6. 释放DbCommand
7. 释放DbConnection

它非常干净，快速且安全，但问题是创建查询有点麻烦，如果我想要类型安全，我必须手动生成和更新“容器类”。这就是我转向实体框架的原因。

仅使用DbConnection和DbCommand这一切都很有效，因为不关心哪个DbConnection / Command对哪个对象或任何内容执行查询。

无论如何，我真的不知道如何在不施加限制的情况下解释它。每次我正常使用DbConnection /命令执行查询，保存它以及处理ObjectContext只会增加太多开销，而我真的不需要频繁更新数据库。

您如何将实体框架用于对数据库没有高要求的游戏服务器立即持续更新？

Answer 1

首先，您需要阅读本文并将其内化：

Performance Considerations for Entity Framework Applications

特别值得注意的是：

1. 正确设置合并选项以进行重新查询
2. 请注意，预生成视图仅适用于像RelatedEnd.Load这样的内容，而不适用于即席查询。使用CompiledQuery优化即席查询。查询准备对于复杂查询来说可能是一个重要的开销，所以尽可能这样做。
3. 如果您已预先生成视图并正确设置合并选项，则实例化和处理对象上下文不会产生大量开销。以对您的应用程序有意义的方式使用它;不要“过早地优化”它的寿命。

Answer 2

您最有可能会注意到与Entity框架性能差异的地方在于数据更新（不是插入）。这是因为数据必须首先从数据库中读取，然后更改，然后保存回数据库。

对于对象上下文，我们使用using语句，以便直接处理它。当垃圾收集器在超出范围的所有对象上运行处理时，游戏暂停是不好的。

如果你主要阅读我会建议缓存数据，例如使用Enterprise Library Caching应用程序块。

实体框架将为您提供更高效的编程模型，而缓存将为您提供更好的性能。

Answer 3

您可能想要查看Subsonic - 它更像是您的小巷，并不会尝试像EF一样聪明，并且由于简单性通常应该更高性能。同时，它很好地覆盖了对象生成角度，因此您无需编写太多样板文件。