Слишком много логики в контроллере против модели, вызывающей друг друга - PullRequest
Новая
       6

Слишком много логики в контроллере против модели, вызывающей друг друга

1 голос
/ 17 июля 2011

Я столкнулся с проблемой разработки кода при работе с небольшим приложением. (Кстати, я новичок)

С точки зрения возможностей, есть список столов, каждый из которых имеет 2 места. Если за одним столом садятся два игрока, начинается игра.

Для этой части у меня есть контроллер таблиц, модель стола и модель состояния игры (создание состояния игры означает, что игра началась).

Когда пользователь садится, он запускает ajax-запрос, который обрабатывается контроллером таблиц, который вызывает соответствующий метод в сидячей модели таблицы. Если модель стола обнаружит, что оба места заполнены, начинается игра, что является сложной задачей.

Я не хотел, чтобы модель состояния игры вызова модели стола была грязной, и отслеживание модели состояния вызова игры может стать затруднительным в дальнейшем. Таким образом, я заставил табличную модель возвращать a: success => true хэш контроллеру таблицы, который определяет, вызывать ли модель игрового состояния.

Но потом я понимаю, что помещаю логику в контроллер, который согласно Rails 3 Way - нет-нет.

Может ли кто-нибудь более опытный, чем я, сказать мне, что я могу сделать лучше?

У меня также есть проблема с "проиграть игру, если пользователь отключил часть". В настоящее время пользователь тянет контроллер стола, чтобы сообщить моему приложению, что он все еще подключен. И эта потеря игры с ручкой части кажется неловкой и сложной.

Кроме того, я заставляю код javascript выполнять одно извлечение setInterval для каждого типа ресурса, чтобы сохранить модульность. Но в результате я делаю 6-7 различных запросов AJAX каждый интервал. И это кажется неэффективным.

1 Ответ

3 голосов
/ 18 июля 2011

Хорошо ... посмотрим.

Сначала нам нужно решить, какие модели знают о каких других моделях.В нашем случае мы, вероятно, можем сказать что-то вроде

GameState -> Table -> User

. Это означает, что модель знает все справа от нее и ничего не знает о модели дляоставил.Таким образом, мы можем легче определить, к чему естественным образом принадлежит много логики, потому что модель User ничего не знает о самой модели Table, она просто знает, что она принадлежит Table.

Теперь,давайте подумаем о различных «состояниях», которые мы имеем в игре.

  1. Состояние перед игрой, когда стол ожидает заполнения
  2. Состояние игры, и, конечно, это будетмного подсостояний
  3. После игры подсчитываются счета, обновляются переменные

Что касается # 1, то мы впервые предполагаем, что это относится к таблице.Он должен знать только о себе и о том государстве, в котором он находится. Но его единственная роль состоит в том, что у него есть два места, и он может быть заполнен.Он не должен знать о том, когда можно запустить игру или что-то еще.Что это значит?Нам на самом деле нужно делегировать работу GameState, потому что предварительная игра также является «состоянием» игры.GameState будет "привратником", если хотите, а таблица - всего лишь пешка.С учетом вышесказанного, будет хорошей идеей, чтобы ваша модель GameState вызывала вашу модель Table, чтобы ВИДЕТЬ, что она может пойти дальше и начать игру.Когда пользователь щелкает, чтобы присоединиться к таблице, он переходит к контроллеру GameState (убедитесь, что ваша логика принадлежит модели, чтобы ваш контроллер просто вызывал методы в вашей модели).Контроллер GameState попытается добавить этого пользователя в таблицу и посмотреть, сможет ли он начать игру (таблица просто возвращается, если все места заполнены).Если это так, он отправляет правильную информацию обратно клиенту и говорит: «Хорошо! Старт!».

После запуска игры GameState может манипулировать собой и данными, которые ему принадлежат (таблица и пользователи, если необходимо).Как только игра закончена, GameState очищает себя (вместе со своими участниками) и архивирует себя в БД.Так что в целом может показаться, что GameState упускает из виду весь процесс, а таблицы / пользователи - это просто данные, которыми манипулирует GameState.

Что касается отключения пользователя, может быть трудно сказать, что правильнообойтись без особого контекста.Но если бы я хотел сделать что-то подобное, не похоже, что вам нужен опрос.Что я могу вспомнить, так это то, что пользователь либо уходит со страницы (либо закрывает браузер, либо набирает новый URL, либо нажимает на ссылку), вы можете использовать unload() для отправки запроса на сервер.говорю вам, что пользователь ушел.Другим способом было бы, если пользователь нажимает «отключить», что также является другим запросом, отправленным на сервер.

С точки зрения необходимости отправлять 6-7 запросов AJAX каждый интервал кажется немного чрезмерным.Если вы действительно хотите, вы должны упаковать все свои ресурсы в один объект, посылать один объект каждый интервал, позволить серверу манипулировать им, а затем обрабатывать его, когда объект возвращается.Но может показаться, что вам не нужны все эти опросы.Единственное, что вам нужно сделать, это проверка и шифрование, если хотите, чтобы убедиться, что GameStates переходят законным путем.

Удачи:)

...