用于在线游戏服务器的类型化数据集或实体框架

我做了一个带有数据库后端的游戏。

提醒一下:在实时游戏中更新缓存是很困难的。你的玩家会一直与你互动。您必须考虑是否要将所有玩家保留在同一台服务器上——如果是这样，缓存很简单，但您将限制增长。如果没有，请考虑如何让人们在同一台服务器上进行交互。例如，聊天服务器可以解决聊天问题。然而，如果你有地理位置，你可能想要按世界区域划分，如果你没有，可能想要保持玩家群体，或者如果你有不同的游戏实例，你可以按此划分。

另一个问题是锁定-你的球员可能访问相同的数据，另一个正在更新。你几乎肯定要处理事务隔离级别——即读未提交将有助于锁定。为此，ADO提供了更多的控制。

但是EF可以让您编写更干净的更新代码，并且如果您按ID更新，性能不会有什么不同。

你可以选择混合——通过ADO读和通过EF写。您甚至可以编写在底层使用ADO的事务性数据库上下文。这样他们看起来很像，但在背景中做不同的事情。

这只是我的想法，我希望这能帮助你找到你的解决方案。

如果你唯一的问题是聊天，你可以为它选择不同的解决方案，使用提供消息和广播的外部云系统…

看看这个链接:http://www.pubnub.com/solutions/how-pubnub-works

希望我能帮上忙

听起来这两种解决方案都不适合您的问题。因此，你的问题就像是在问，是用湿报纸还是用伞往墙上钉钉子……不管答案是什么，你可能都不应该这么做。

EF有很多限制和怪癖，并且确实有一些开销。如果你真的想坚持使用3.5(在我看来这是一个糟糕的选择，但是嘿)，那么我不会推荐它——除非你已经习惯了它，包括如何解决任何性能问题。

数据集就是一个讨厌的东西。我的专业信念是，它们的发明是为了让微软能够为Visual Studio提供5分钟的拖放代码演示，以说服所有的VB程序员转向。net。与所有东西相比，它们都异常缓慢(尽管. net 2.0的性能至少是线性扩展的)。

我不确定您应该使用什么产品，但我知道有内存关系数据库允许您存储事务日志和偶尔的快照，以便在服务器死机(或IIS重新启动等)时方便回滚，这以牺牲可伸缩性为代价提供性能(您的整个数据库必须适合内存)。

另一个选择是使用NoSQL数据库(如MongoDB)，它可以很好地跨多个服务器扩展，并允许您将所有相关数据捆绑到单个文档中(因此您在查询数据时不会有连接表的所有开销)。

这些选择中的任何一个都将比最初的两个建议中的任何一个更适合。