我需要一个适合有状态应用程序的 ORM。我将在具有持久客户端连接的低延迟实时游戏服务器中保持请求之间的实体。只有 1 个服务器实例连接到数据库，因此无法从“外部”更改任何数据，服务器可以依赖其缓存。
当用户远程登录到服务器时，其整个配置文件将加载到服务器内存中。还为每个用户创建了几个更高级别的服务来操作配置文件数据并提供功能。它们还可以有内部字段(状态)来存储临时数据。当用户想要更改他的签名时，他要求相应的服务这样做。该服务跟踪用户更改其签名的频率，并且每十分钟仅允许一次(例如)-db 中不会跟踪如此短的间隔，这是一个临时状态。此更改应存储到仅执行 1 个查询的数据库中:UPDATE users SET signature = ... WHERE user_id = ...。当用户注销时，它会在几分钟/几小时不活动后从服务器内存中卸载。这里的db只是一个存储。这就是我所说的有状态。
- 一些实体被认为是“静态数据”并且只在应用程序启动时加载一次。这些可以从其他“动态”实体中引用。加载“动态”实体不应需要重新加载引用的“静态数据”实体。
Update/Insert/Delete应该只设置/插入/删除更改的属性/实体，即使是“分离的”实体也是如此。- 写操作不应每次都从数据库加载数据(执行
Select)以检测变化。 (可以在动态生成的继承者中跟踪状态。)我在本地有一个状态，加载任何东西都没有意义。 即使在连接范围之外，我也想继续跟踪更改，并在需要时“上传”更改。 - 在执行操作时，不应更改持久化对象的引用。
- DBConnection-per-user 将无法工作。预计在线用户数为数千。
- 来自“静态数据”的实体可以分配给“动态”实体属性(表示外键)，
Update应该正确处理它。
现在我正在使用 NHibernate，尽管它是为无状态应用程序设计的。它支持重新附加到 session ，但这看起来非常不常见，需要我使用未记录的行为并且不能解决所有问题。
我不确定 Entity Framework - 我可以那样使用它吗？或者你能推荐另一个 ORM 吗？
如果每次用户点击按钮时服务器都会重新创建(或特别是重新加载)用户对象，那么它会非常快地占用 CPU。 CPU 垂直扩展代价高昂但效果很小。相反，如果你没有 RAM，你可以去购买更多——就像水平缩放一样，但更容易编码。如果您认为这里应该使用另一种方法，我准备讨论它。
最佳答案
是的，您可以将 EF 用于此类应用程序。请记住，在重负载下，您会不时遇到一些数据库错误。通常，当您的应用程序跟踪更改而不是 EF 时，错误后恢复速度更快。顺便说一下，您也可以通过这种方式使用 NHibernate。
关于c# - 用于有状态应用程序的 ORM。 EF适合吗？或者任何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32688492/