1

我在处理一个小型应用程序时遇到了代码设计问题。（顺便说一句，我是初学者）

在功能方面，有一张桌子列表，每张桌子有 2 个座位。如果两个玩家坐在同一张桌子上，那么游戏就开始了。

对于这一部分，我有一个表控制器、一个表模型和一个游戏状态模型（创建游戏状态意味着游戏已经开始）。

当用户坐下时，它会触发一个由表格控制器处理的 ajax 请求，该请求会调用表格模型中的适当方法进行坐下。如果桌子模型发现两个座位都坐满了，游戏就开始了，这是棘手的部分。

我不想让表格模型调用游戏状态模型，因为它感觉很混乱，并且以后跟踪谁调用游戏状态模型可能会变得困难。所以我让表模型返回一个 :success=>true 哈希给表控制器，表控制器决定是否调用游戏状态模型。

但后来我意识到我正在将逻辑放入控制器中，根据 Rails 3 Way，这是一个禁忌。

比我更有经验的人能告诉我什么可以做得更好吗？

我也遇到“如果用户断开连接则放弃游戏”的问题。目前，用户拉动表控制器是为了让我的应用知道他仍然连接。让那部分处理游戏没收似乎很尴尬和耦合。

此外，我让 javascript 代码为每种类型的资源执行一次 setInterval 拉取，以尝试保持模块化。但结果，我每间隔发出 6-7 个不同的 AJAX 请求。这似乎效率低下。

4

1 回答 1

3

好吧..让我们看看。

首先，我们需要决定哪些模型知道哪些其他模型。在我们的例子中，我们可能会说类似

游戏状态 -> 表格 -> 用户

这意味着模型知道它右边的一切，而对左边的模型一无所知。这样，我们可以更容易地确定很多逻辑自然属于哪里，因为 User 模型对 Table 模型本身一无所知，它只知道它属于一个 Table。

现在，让我们考虑一下我们在游戏中拥有的不同“状态”。

  1. 桌子等待被填满的赛前状态
  2. 游戏状态，当然这会有很多子状态
  3. 比赛结束后，计算得分，更新变量

关于#1，我们的第一个猜测是它属于表。它应该只知道自己和自己所处的状态。但它的唯一作用是它有两个座位，并且可以被填满。它不应该知道什么时候可以开始游戏或任何事情。这是什么意思？我们实际上需要将工作委托给 GameState，因为游戏前也是游戏的“状态”。如果您愿意，GameState 将成为“看门人”，而 Table 只是一个棋子。话虽如此，让您的 GameState 模型调用您的 Table 模型以查看它是否可以继续并开始游戏将是一个好主意。当用户点击加入表格时，它将转到 GameState 控制器（确保您的逻辑属于模型，以便您的控制器只是调用模型中的方法）。GameState 控制器将尝试将此用户添加到表格中，并查看它是否可以开始游戏（如果所有座位都已填满，表格只会返回）。如果是这样，它将正确的信息发送回客户端并说：“好的！开始！”。

一旦游戏开始，就由 GameState 来操作自己和属于它的数据（如果需要的话，可以使用表和用户）。游戏结束后，GameState 会自行清理（连同它的成员）并将自己归档到数据库中。所以总而言之，GameState 似乎忽略了整个过程，而 Tables/Users 只是 GameState 操作的数据。

关于用户断开连接，如果没有太多上下文，很难说什么是正确的做法。但如果我要制作这样的东西，你似乎不需要投票。我能想到的是用户要么离开页面（关闭浏览器、输入新的 url 或单击链接），你可以使用unload()它向服务器发送请求，告诉你用户离开了。另一种方法是如果用户单击“断开连接”，这也是发送到服务器的另一个请求。

就必须发送 6-7 个 AJAX 请求而言，每个间隔似乎有点过分。如果你真的想，你应该把你所有的资源打包成一个对象，每隔一段时间发送一个对象，让服务器操作它，然后在对象回来时处理它。但是，您似乎也不需要所有这些轮询。您唯一需要做的就是验证和加密，以确保 GameStates 以合法的方式转换。

祝你好运 ：）

于 2011-07-17T21:02:04.640 回答