实体框架与游戏服务器

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那样聪明，并且通常会因为简单性而更具性能。同时它很好地覆盖了对象生成角度，因此您不会有太多的样板文字可供编写。