我在处理小型应用程序时遇到了代码设计问题。 （顺便说一下，我是初学者）
就功能而言，有一个表格列表，每个表格有2个席位。如果两个玩家坐在同一张桌子上，那么游戏就会开始。
对于这部分，我有一个表控制器，一个表模型和一个游戏状态模型（创建游戏状态意味着游戏已经开始）。
当用户坐下时，它会触发由表控制器处理的ajax请求，该控制器调用表模型中的相应方法进行坐位。如果桌面模型发现两个座位都已填满，则游戏开始，这是一个棘手的部分。
我不想让桌面模型调用游戏状态模型，因为它感觉很乱，跟踪调用游戏状态模型可能会在以后变得困难。所以我让表模型返回一个：success =＆gt; true hash to table controller，它决定是否调用游戏状态模型。
但后来我意识到我把逻辑放在控制器中，根据Rails 3 Way，这是一个禁忌。
有人比我更有经验告诉我我能做得更好吗？
如果用户断开连接部分，我也会遇到“没收游戏”的问题。目前，用户拉出表控制器，以便让我的应用程序知道他仍然连接。而那部分处理游戏没收的东西似乎很尴尬和耦合。
此外，我正在使javascript代码为每种类型的资源执行一次setInterval pull，以尝试保持模块化。但结果是，我每隔一段时间就会产生6-7个不同的AJAX请求。这似乎效率低下。
答案 0 :(得分：3)
好的..小时候看。
首先，我们需要确定哪些模型了解哪些模型。在我们的例子中，我们可以说像
GameState - ＆gt;表 - ＆gt;用户
这意味着模型知道它右侧的所有内容，并且对左侧的模型一无所知。这样，我们可以更容易地确定很多逻辑自然属于哪里，因为用户模型对表模型本身一无所知，只知道它属于表。
现在，让我们考虑一下游戏中的不同“状态”。
关于＃1，我们首先猜测这属于表。它应该只知道自己和自己所处的状态。但它唯一的作用是它有两个席位，而且可以填补。它不应该知道何时可以开始游戏或任何事情。这是什么意思？我们实际上需要将作业委托给GameState，因为游戏之前也是游戏的“状态”。如果你愿意，GameState将是“守门人”，而桌子只是一个棋子。有了这个说法，让你的GameState模型调用你的Table模型是个好主意，看看它可以继续开始游戏。当用户单击以加入表时，它将转到GameState控制器（确保您的逻辑属于模型，以便您的控制器只调用模型中的方法）。 GameState控制器将尝试将此用户添加到表中并查看它是否可以启动游戏（如果所有座位都已填满，则表格仅返回）。如果是这样，它会将正确的信息发送回客户并说：“好的！开始！”。
一旦游戏开始，那么由GameState来操作自己以及属于它的数据（表和用户，如果需要的话）。游戏结束后，GameState会自行清理（连同它的成员）并将自己存档到数据库中。总而言之，似乎GameState忽略了整个过程，而表/用户只是GameState操纵的数据。
关于用户断开连接，很难说在没有太多上下文的情况下做什么是正确的。但如果我要做这样的事情，你似乎不需要投票。我能想到的是用户导航离开页面（关闭浏览器，输入新网址或点击链接），您可以使用unload()向服务器发送请求，告诉您用户离开了。另一种方式是用户点击“断开连接”，这也是发送到服务器的另一个请求。
就必须发送6-7个AJAX请求而言，每个间隔似乎有点过分。如果你真的想要，你应该将所有资源打包成一个对象，每隔一段时间发送一个对象，让服务器操纵它，然后在对象回来时处理它。但似乎你不需要所有这些民意调查。您需要做的唯一事情就是验证和加密，以确保GameStates以合法的方式进行转换。
祝你好运：）