ORM用于有状态的应用程序。 EF适合吗？或者任何？

Question

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

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

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

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

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

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

Answer 1

是的，您可以将EF用于此类应用程序。请记住，在重负载时，您会不时地遇到一些db错误。通常情况下，当应用程序跟踪更改而不是EF时，错误后恢复的速度会更快。顺便说一下，你也可以这样使用NHibernate。

Answer 2

我在具有极长会话的有状态桌面应用程序中使用了hibernate：会话在应用程序启动时启动，并且只要应用程序正在运行，它就会保持打开状态。我没有遇到任何问题。我绝对不使用附加，分离，重新连接等。我知道这不是标准做法，但这并不意味着它不可行，或者有任何陷阱。 （编辑：但当然请阅读下面的讨论，了解其他人可能存在的陷阱。）

我甚至已经实现了我自己的更改通知机制，（单独的线程直接轮询数据库，绕过hibernate），因此甚至可以让外部代理在hibernate运行时修改数据库，并让你的申请时要注意这些变化。

如果你有许多已经在使用hibernate的东西，放弃你已经拥有的东西并重写它可能不是一个好主意，除非你确定hibernate绝对不会做你想要完成的事情。