Как написать многоразовую бизнес-логику в моделях MVC?

Question

Моя проблема в том, что мы пытаемся использовать инфраструктуру MVC (PHP).После долгих обсуждений думаю, что MVC очень хорош, но я упускаю возможность написать многократно используемую логику модели (приложения).Поэтому я не уверен, что у нас есть правильный подход для реализации нашего программного обеспечения в среде MVC.

Сначала я опишу не-MVC, oo-подход, который мы используем в данный момент.

Например - мы работаем над некоторыми браузерными играми (да, это наша профессия).Представьте, что у нас есть объект игрока.Мы используем этот объект игрока очень часто.У нас есть несколько разных страниц, где вы можете купить мысли, поэтому вам нужно совершать «денежные» транзакции на «банковском счете» игроков или представлять, что вы можете сражаться с другими игроками.У нас есть несколько сценариев боя, и эти сценарии принимают 2 или более объектов игрока (это зависит от типа битвы, например, битва клана, битва игрок против игрока ...).

Итак, у нас есть несколькостраницы (и контроллеры) с различной боевой логикой.Но каждый из этих контроллеров использует объект игрока для вычисления всех атрибутов и предметов, которые есть у игрока, и какой урон и защита будет наносить игрок.

Итак, как мы можем повторно использовать логику в объекте игрока в случае, еслимодели MVC?было бы плохо дублировать всю необходимую логику в различных контроллерах и -моделях.

Я думаю, что логика "gold -action" была бы хорошим примером, чтобы дать вам более подробную информацию.вам нужна транзакционная функция в случае боя, если вы выигрываете у другого игрока и забираете часть его золота, вам нужна транзакционная функция в случае покупки какого-либо предмета и вам нужна транзакционная функция в случае траты некоторого золотадля гильдии игроков ...

Так что, я бы сказал, было бы плохим подходом определять все эти функции в одной модели игрока!Я могу сказать, что эта модель игрока будет очень большой (на самом деле у нас проблема в том, что наш класс игрока действительно огромный - класс бога)

Как вы думаете, есть решение в стиле MVC для этой проблемы?

Answer 1

Я бы сказал, что вы помещаете код там, где он наиболее целесообразен, и где вам не нужно дублировать его где-то еще.

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

Если у вас возникают проблемы с выяснением того, куда должна идти логика, возможно, это связано с тем, что ваши функции недостаточно детализированы и могут быть использованы повторно.Несомненно, есть аспекты MVC, которые заставляют вас задуматься о разделении интересов и сохранении СУХОЙ сущности больше, чем «простой» ООП-подход ... так что вы можете в конечном итоге разбить кодируемые в данный момент операции, которые находятся в одномтеперь функционируйте в нескольких функциях разных классов, чтобы получить правильный код в нужных местах.

Например - и это вовсе не конкретные предложения, а просто случайный возможный мыслительный процесс - возможно, процесс передачи 'золото между игроками должно быть разбито на более детальные процессы.Класс игрока может выполнять основную задачу по изменению баланса, но затем контролер (-ы) могут выполнять определенные части процесса, такие как проверка / от кого переводится золото и почему.