代码之家 › 专栏 › 技术社区 › Spodi

带有游戏服务器的实体框架

entity-framework multithreading .net c#

Spodi · 技术社区 · 17 年前

我一直在研究在我的C游戏服务器中使用实体框架来简化查询。我非常喜欢类型安全,并且实体框架在自动化大多数样板代码方面做得很好。尽管我不太确定如何使用某些组件,即 ObjectContext .

服务器使用了大量线程,因此线程安全是一个问题。现在,我只使用自定义池来执行查询。在不详细介绍的情况下,每个查询的工作方式如下:

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

所有这些都很好地使用 数据库连接类 和 数据库命令 因为不关心 数据库连接类 /命令为哪个对象或任何对象执行查询。

不管怎样,我真的不知道如何不加限制地解释它。做一些类似于每次正常使用 数据库连接类 /命令、保存它和处理ObjectContext只会在我确实不需要如此频繁地更新数据库时增加太多的开销。

如果游戏服务器对数据库的即时性和实时性要求不高,那么如何使用实体框架呢?

3 回复 | 直到 13 年前

Shiraz Bhaiji 17 年前

您最可能注意到的地方是更新数据(而不是插入)与实体框架在性能上的差异。这是因为必须先从数据库中读取数据,然后更改,然后再保存回数据库。

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

如果您主要阅读,我建议您缓存数据,例如使用企业库缓存应用程序块。

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

Craig Stuntz 17 年前

首先,您需要阅读并将其内化:

特别注意:

为只重复查询正确设置合并选项
注意,视图的预生成只对RelatedEnd.Load之类的东西有帮助,而对特殊查询没有帮助。使用compiledquery优化即席查询。对于复杂的查询,查询准备可能是一个很大的开销,因此尽可能这样做。
如果预先生成了视图,并且正确地设置了合并选项,那么实例化和处理对象上下文就没有太多开销。以对应用程序有意义的方式使用它;不要“过早地优化”它的生命周期。

Wyatt Barnett 17 年前

你可能想看看亚音速——它比英孚要高得多,而且不会像英孚那样聪明,而且由于它的简单性,一般来说应该表现得更好。同时,它很好地覆盖了对象生成角度,因此您将没有太多的样板需要编写。

推荐文章

Bass · @Volatile lateinit变量可以在Kotlin中使用DCL模式进行原子初始化吗?

1 年前

bepopov · 无法在继承的Thread类中将值设置为Inheritable ThreadLocal字段

1 年前

Starnec · Anticapte FileHooser关闭以中止正在运行的任务

1 年前

user107586 · 如何处理等待句柄不会导致无限循环?

1 年前

ron burgundy · 获取-释放语义是否跨线程传递?[副本]

1 年前

BenjiFB · C#内存缓存:在一次操作中追加到列表?

1 年前

Adam Rutledge · 让父线程在初始化子线程pthread后等待,直到它从子线程接收到一些信号的最佳方法是什么?

1 年前

András Takács · Python多线程问题

2 年前

András Takács · Python多线程错误

2 年前

eden sson · 使用std::thread和native_handle()设置线程关联掩码

2 年前