我的问题是我们尝试使用 MVC (PHP) 框架。在讨论了很多之后认为 MVC 非常好，但我错过了编写可重用模型(应用程序)逻辑的可能性。所以，我不确定我们是否有在 MVC 框架中实现我们的软件的正确方法。
首先，我将描述我们目前使用的非 MVC、oo 方法。
例如 - 我们正在开发一些浏览器游戏(是的，这是我们的职业)。假设我们有一个玩家对象。我们经常使用这个玩家对象。我们有一些不同的页面，您可以在其中购买思想，因此您需要在玩家的“银行账户”上进行“金钱”交易，或者想象您可以与其他玩家进行战斗。我们有几个战斗脚本，这些脚本需要 2 个或更多玩家对象(这取决于战斗类型，即部落战斗、玩家对玩家战斗......)。
因此，我们有几个具有不同战斗逻辑的页面(和 Controller )。但是每个 Controller 都使用玩家对象来计算玩家拥有的所有属性和元素，以及玩家将进行的伤害和防御。
那么，在 MVC 模型的情况下，我们如何重用播放器对象中的逻辑？在不同的战斗 Controller 和模型中复制所有必要的逻辑是不好的。
我认为“黄金交易”逻辑将是一个很好的例子，可以为您提供更多详细信息。打架时你需要交易功能，如果你战胜了其他玩家并掠夺了他的一些金币，你需要交易功能来购买一些东西，你需要交易功能来消费一些金币到玩家公会...
所以，我会说在一个玩家模型中定义所有这些功能是一种糟糕的方法!我可以说你这些玩家模型会非常大(实际上我们的问题是我们的玩家等级真的很大 - 它是一个神等级)
你认为这个问题有 MVC 风格的解决方案吗？
最佳答案
我会说你把代码放在最有意义的地方，你不需要在其他地方复制它。
如果某些操作总是需要 Player 对象，但可能会在不同的 Controller 之间使用，那么 Player 类将是放置它的合乎逻辑的位置。另一方面，如果一些逻辑只需要在某个 Controller 的上下文中完成，并且可能涉及其他类，那么它可能应该在 Controller 中 - 或者也可能在其他某个类中。
如果您在弄清楚逻辑应该去哪里时遇到问题，可能是因为您的函数不够细化和可重用。 MVC 的某些方面肯定会迫使您更多地考虑关注点的分离和保持事物的干燥，而不是“普通”的 OOP 方法……所以您最终可能会分解当前编码的操作，这些操作位于单个函数现在变成不同类上的多个函数，以在正确的位置获得正确的代码。
例如——这些根本不是具体的建议，而只是一个随机可能的思考过程——也许玩家之间转移“黄金”的过程需要分解成更细粒度的过程。玩家类可能会执行更改余额的基本任务，但随后 Controller 可能会执行该过程的特定部分，例如验证向/从谁转移黄金以及原因。
关于model-view-controller - 如何在 MVC 模型中编写可重用的业务逻辑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3892396/