title: How to handle too much logic in the controller vs the models calling each other
body: <p>I encountered a code design problem while working on a small application.</p>
  <p>In terms of features, there are a list of tables, each having 2 seats. If two players sit down at the same table, then a game starts.</p>
  <p>For this part, I have a tables controller, a table model, and a game state model (creating a game state means a game has started).</p>
  <p>When a user sits down, the code fires an Ajax request which is handled by the tables controller, which calls the appropriate method in table model for sitting. If the table model finds out both seats are filled, the game starts, which is the tricky part.</p>
  <p>I didn't want to have the table model call game state model because it feels messy and tracking who is calling the game state model may become difficult later on. So I made the table model return a :success=&gt;true hash to table controller, which determines whether to call game state model.</p>
  <p>But then I realize I'm putting logic in the controller, which according to Rails 3 Way, is a no-no.</p>
  <p>Can someone tell me what I can do better?</p>
  <p>I'm also having problem with &quot;forfeit the game if user disconnects part&quot;. Currently the user pulls the table controller in order to let my app know hes still connected. And having that part handle game forfeit seems awkward and coupling.</p>
  <p>Additionally, I'm making the JavaScript code do one <code>setInterval</code> pull for each type of resource, in an attempt to keep things modular. But as a result, I'm making 6-7 different AJAX requests every interval. And that seems inefficient.</p>