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