ORM用于有状态的应用程序.EF适合吗？还是任何？

Question

我需要一个适合有状态应用的ORM.我将在具有持久客户端连接的低延迟实时游戏服务器中的请求之间保留实体.只有一个服务器实例连接到数据库,因此无法从"外部"更改数据,服务器可以依赖其缓存.

当用户远程登录服务器时,其整个配置文件将加载到服务器内存中.还为每个用户创建了几个更高级别的服务,以操作配置文件数据并提供功能.它们还可以具有内部字段(状态)来存储临时数据.当用户想要改变他的签名时,他要求相应的服务这样做.该服务跟踪用户更改其签名的频率,并且每十分钟仅允许一次(例如) - 在db中不跟踪这样的短间隔,这是临时状态.此更改应存储到仅执行1个查询的db : UPDATE users SET signature = ... WHERE user_id = .... 当用户注销时,它会在几分钟/小时不活动后从服务器内存中卸载.这里的Db只是一个存储空间.这就是我称之为有状态的.

1. 某些实体被视为"静态数据",仅在应用程序启动时加载一次.那些可以从其他"动态"实体引用.加载"动态"实体不应要求重新加载引用的"静态数据"实体.
2. Update/ Insert/ Delete应该设置/插入/偶与"抽离"实体只删除更改的属性/实体.
3. 写操作不应每次都从数据库(执行Select)初步加载数据以检测更改.(可以在动态生成的继承器中跟踪状态.)我在本地有一个状态,没有意义加载任何东西.我希望在连接范围之外继续跟踪更改,并在需要时"上传"更改.
4. 执行操作时,不应更改持久对象的引用.
5. 每个用户的DBConnection不起作用.预期的在线数千名用户.
6. 来自"静态数据"的实体可以分配给"动态"enitity属性(表示外键)并且Update应该正确处理它.

现在我正在使用NHibernate,尽管它是为无状态应用程序设计的.它支持重新连接到会话,但看起来非常罕见的使用,要求我使用未记录的行为,并不解决所有问题.

我不确定实体框架 - 我可以这样使用它吗？或者你能建议另一个ORM吗？

如果服务器每次用户按下按钮时都会重新创建(或特别是重新加载)用户对象,那么它将非常快地占用CPU.CPU垂直扩展成本很高但效果很小.相反,如果你没有RAM,你可以去买更多 - 比如水平缩放,但更容易编码.如果你认为应该在这里使用另一种方法,我准备讨论它.

Answer 1

是的，您可以将 EF 用于此类应用程序。请记住，在重负载下，您有时会遇到一些数据库错误。通常，当您应用程序跟踪更改（而不是 EF）时，发生错误后恢复速度会更快。顺便说一下，你也可以用这种方式使用 NHibernate。