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