我的游戏是回合制的，但它确实有一些实时元素，比如聊天，所以它需要速度。理想情况下，一台服务器应该支持几千个在线玩家。
我知道数据集倾向于在内存中存储大量数据，但我认为这就是我需要避免每毫秒执行两次 db 调用所需要的。我正在远离实体框架，因为我似乎对引擎盖下发生的事情没有太多控制权，而且不知何故它让我觉得效率较低。
现在我知道这些（也不是一般的 c#）都不是生活中存在的最快速的解决方案，但我确实需要一点便利。
顺便说一句，由于其他一些不确定的依赖关系，我不能轻易使用 .Net 4.0。这些可以修复，但老实说，我不想花时间解决这个问题。我宁愿坚持使用 3.5，我的依赖项可以很好地使用。
我用数据库后端做了一个游戏。
智者的话：在实时游戏中更新缓存是很困难的。您的玩家将一直在互动。您必须考虑是否要将所有玩家保持在同一服务器上 - 如果是这样，缓存很简单，但您会限制增长。如果没有，想想如何让人们在同一台服务器上进行交互。例如，聊天服务器将解决聊天问题。但是，如果您有地理，您可能希望按世界区域划分，如果没有，可能希望保留玩家组，或者如果您有不同的游戏实例，则可以按此划分。
另一个问题是锁定 - 您的玩家可能会访问其他人正在更新的相同数据。您几乎可以肯定必须处理事务隔离级别 - 即未提交的读取将有助于锁定。为此，ADO 提供了更多控制。
但是 EF 可以让您编写更清晰的更新代码，并且如果您按 ID 更新，性能不会有所不同。
您可以混合使用 - 通过 ADO 读取并通过 EF 写入。您甚至可以编写一个在下面使用 ADO 的事务性数据库上下文。这样他们看起来很相似，但在后台做不同的事情。
只是我的想法，我希望这可以帮助您找出解决方案。
听起来这两种解决方案都不适合您的问题。因此，您的问题就像询问是否使用湿报纸或雨伞将钉子钉入墙上。无论答案如何，您可能都不应该这样做。
EF 有很多限制和怪癖，并且确实有一些开销。如果您真的想坚持使用 3.5（我认为这是个糟糕的选择，但是嘿），那么我不会推荐它 - 除非您已经对它感到满意，包括如何解决任何性能问题。
数据集只是一个可憎的。我的专业信念是，它们的发明是为了让微软能够为 Visual Studio 提取 5 分钟的拖放式编码演示，以说服所有 VB 程序员切换到 .NET。与几乎所有东西相比，它们都异常缓慢（尽管由于 .NET 2.0 的性能至少可以线性扩展）。
我不确定您应该使用什么产品，但我知道内存中的关系数据库允许您存储事务日志和偶尔的快照，以便在您的服务器死机（或 IIS 重新启动，等），它以可伸缩性为代价为您提供性能（您的整个数据库必须适合内存）。
另一种选择是使用 NoSQL 数据库（例如 MongoDB），它可以很好地跨多个服务器扩展，并允许您将所有相关数据捆绑到一个文档中（这样您在查询数据时就没有连接表的所有开销）。
这些选项中的任何一个都将比两个原始建议中的任何一个更合适。
如果您唯一的问题是聊天，您可以为它选择不同类型的解决方案，使用提供消息传递和广播的外部云系统......
查看此链接： http ://www.pubnub.com/solutions/how-pubnub-works
希望我能以某种方式帮助