MVC-问题还是解决方案？

>存储库，适配器，MVC，固体，RTFM…网络不断地将这些术语抛向PHP开发人员。 我厌倦了。足够的命令；告诉我小猫！

>

密钥点：

MVC不是Web应用程序复杂性的魔术子弹。 干净，可重复使用，脱钩的代码是真正的解决方案，这取决于开发人员。 与任何模式一样，MVC是一种工具。 使用良好，它可以提高灵活性和易用性。但这是极限用途和滥用的。
>不要盲目应用模式。了解他们的优势和缺点；选择适合工作的正确工具。
软件解决问题：

我们构建了解决问题的软件。 每条代码都解决了特定的需求，无论是拯救世界还是展示可爱的小猫。 尊重该目的。 这些问题的解决方案融合到较大的系统中。 但是，我们如何确保我们的解决方案有效，可理解和可维护？

“一个尺寸适合所有”神话：

> MVC通常是Web应用程序的唯一可行解决方案。 社区经常批评那些不使用它的人，很少解释为什么

MVC据称是优越的。

>

为什么MVC炒作？ 通常引用的好处包括：

降低代码复杂度

>代码可重用性

提高灵活性

脱钩代码

但是这些主张是真的吗？其他模式是否缺乏这些优势？ 编号
MVC并不能固有地解决复杂性，可重复性，灵活性或去耦。
• >开发人员
编写干净，灵活和可重复使用的代码。 我们不需要MVC比需要jQuery使用
• 。 出色的软件在MVC之前就已经存在了，并且将继续没有它。
> MVC是一种模式，而不是灵丹妙药。 这是众多：适配器，工厂，单例，模块，口译员，观察者...

模式有助于他们无法解决：

> >模式可帮助我们编写更好的代码。它们代表最佳实践，但最佳实践取决于问题。船非常适合水旅行，而不是耕地。 document.getElementById()每个模式都有优势和劣势。工厂模式在对象创建时出色。模块模式有助于在缺乏强大模块支持的语言中构造代码（例如JavaScript）。观察者模式在事件处理中闪耀。 MVC有助于解耦演示，数据和逻辑。 MVC的过度使用源于误导的信念，即这是PHP Web应用程序的通用解决方案。 出现了严格的规则：模型镜像数据库行，薄控制器，模板引擎...然后是“脂肪控制器”以及HMVC，MVA，MVP，MVP，MVP，MVVM，PAC，PAC ...

的扩散。

> mvc：新的singleton（或IE8）：

>MVC并不孤单。 正如基思（Keith）指出的那样，单身模式被过度使用，以避免全球的邪恶，导致

而不是Global::getInstance()->var>。 $globalVar>

模式是工具，开发人员是手工艺人：

> >模式很有价值，但明智而周到地使用它们。 没有什么比开发人员误用模式更糟糕的了。>

不要重新发明轮子。 许多聪明的开发人员在您面前解决了类似的问题。

>在PHP中与数据库集成斗争？ MVC或多层体系结构可能会有所帮助。 懒惰加载问题？ 单身可能是合适的。 物体创造麻烦？ 工厂模式可以帮助您。 服务间沟通问题？ 适配器是您的朋友。

结论：

>不同的模式提供了不同的好处。根据问题明智地选择。 如果您将MVC用于单页应用程序，请删除它。> 可能与您同在！

>

经常询问有关MVC和PHP框架的问题：

>

（本节在很大程度上保持不变，因为它是MVC和PHP框架的良好概述）。以及它们对各种项目类型的适用性。 这里不需要更改。>

以上是MVC-问题还是解决方案？的详细内容。更多信息请关注PHP中文网其他相关文章！