开发自己的 PHP MVC 框架（例如 codeigniter）我们应该知道什么 [关闭]答案

【问题标题】：What should we know to develop our own PHP MVC frame work (such as codeigniter) [closed]开发自己的 PHP MVC 框架（例如 codeigniter）我们应该知道什么 [关闭]
【发布时间】：2019-06-08 15:42:50
【问题描述】：

一位面试官问了我一个有趣的问题“如果我要求你创建自己的 MVC 框架，你应该已经知道哪些事情”。除了以前端控制器为基础并相应地重定向我们的请求之外，我几乎无法给出具体的答案。如果有人能提供一些启示，我会很高兴。

【问题讨论】：

我认为这一切的核心是一个路由器（如您所描述的），然后了解文件系统、依赖项和 OOP 以使控制器工作。最终，它取决于您的应用程序在确定应用程序的构建程度时可以有多复杂或紧密耦合。我可能会要求一个关于它将是什么类型的网站的一般示例：电子商务？个人的？。ETC。确定我将如何继续回答这个问题。一般来说，codeigniter 只适用于非常简单的网站，因为它的依赖注入和通用设计不适合扩展能力

标签： php model-view-controller

【解决方案1】：

你的答案应该是：

基于 MVC 的应用程序遵循separation of concerns 原则。第一个分离：UI 逻辑与业务逻辑（"M" 组件）。第二个分离（与 UI 逻辑有关）：用户请求调度逻辑（"C" 组件）与表示逻辑（"V" 组件）。
“M” 组件不知道任何其他应用程序组件，并且以这样的方式实现，它可以被多个应用程序（甚至是不同类型的）共享。
可以以不同的方式对每个组件进行建模和实现。在这里可以讨论，根据要求，应该使用哪些对象以及它们应该如何相互交互...... 换句话说，这是你“很难给出具体答案”的部分.下面是一个示例，展示了我选择的使用 MVC 的 Web 应用程序工作流程的方法。
（使用）MVC 模式开发应用程序的优点：组件可重用性、良好的可测试性、基于开发人员的专业化对某个组件进行更改的可能性。 通过查看/阅读此答案末尾发布的第一个资源，可以发现其他优势。
至于缺点：增加了复杂性（我个人看不到任何其他）。
Object-oriented programming、SOLID principles、clean architecture、clean code、design patterns、unit testing等

实现 MVC 的 Web 应用程序示例：

这里是我选择的使用 MVC 的 Web 应用程序工作流方法的概述 - 主要受到 Robert Martin 的演讲 Keynote: Architecture the Lost Years 的启发，并试图尊重 Trygve Reenskaug 在 1979 年提出的原始 MVC 模式的工作流（例如控制器更新模型，视图从中提取数据，与控制器无关）。

您可以在我的older answer 中阅读有关每个组件的更多详细信息。

一些资源：

【讨论】：

加一为所有努力。这是完整答案的定义
@ChrysovalantisKoutsoumpos 感谢您的赞赏！

【解决方案2】：

我想这个问题最简单的答案就是准确地解释什么是 php mvc 框架，它的作用以及谈论你偶尔在框架中使用的所有 classes 有什么好处，你不能没有它工作：

配置
URI
输入
输出
语言
加密
等

并简述每一个的用法，说说数据库类：

数据库配置
连接
查询生成器
等

也许可以谈谈loaders、libraries、helpers等等

【讨论】：

【解决方案3】：

如果我曾经遇到过这个问题，我会建议提问者退后一步，想想他想要解决的问题。

我会回答这个问题：How you end up believing that building an MVC framework from scratch will provide solution to your problem?

MVC 模式有一些很大的优点，但也有很大的缺点。在 PHP 的演进过程中，几年前我们把自己介绍到了 MVC 框架的时代，非常棒！更快更简单的开发过程，大量的魔法，活跃的记录等。

随着 PHP 社区的发展，我们现在正以艰难的方式学习过去的错误。极高的耦合、极端情况的继承、全局变量的使用和违反每条 SOLID 规则的实现。 MVC 被框架滥用，它们的实现方式根本是错误的！中间件的概念将是 MVC 框架衰落后唯一的继承。

因此，除了可能引发的代码可重用性问题之外，为了构建（或更好地启动/建议）一个 (MVC) 框架，我认为技术知识是您最不需要的。您需要遵循 PHP 和 PHP Framework 的演进路径，并从过去的错误中吸取教训，以便做出选择。

【讨论】：

这可能不是“我有 x 个问题超出了目前市场上任何 MVC 的范围，因此我必须构建自己的 MVC”，而更多的是“你真的了解如何 MVC 工作？通过告诉我一些核心方法来证明这一点（包括优点/缺点，如果你想要每种方法）“......我忘了是谁说的，但真正的掌握是能够理解一些足以简单解释的东西，我认为这就是这里的目标。
感谢您的评论@Alex！实际上，在再次阅读问题而不是匆忙之后，我认为您是对的。不过，我正在考虑保留我的答案，因为 IMO 对于在您解释它时有第一个问题的人了解我如何看待它是有好处的
如果可以的话，Chrysovalantis，我不同意你的说法 “MVC 根本上是错误的”。分离关注点是正确的做法。所以，使用 MVC 模式是基本正确的。但是，基于 MVC 的各种应用程序（也可以是 Web 框架）可能会被错误地实现。而且，在我看来，您所说的最大缺点是这种实现的效果，而不是 MVC 模式的效果。至于中间件，在我看来，它们要么只是 MVC 的“C”组件的替代品，要么是对其的补充。 MVC 的“V”和“M”组件保持不变。
哦，是的，我也不同意那部分。 mvc 是解决方案而不是问题。但是codeigniter是mvc“错误”类型的一个很好的例子。但是，imo，它适用于小型应用程序。
好收获！我的意思是“使用框架实现方式的 MVC”，正如您所描述的 @dakis。我会将该部分修改为具体，因为它会造成混乱。当然，将 MVC 作为一种模式并没有什么坏处。我也同意，尽管我认为对于小型项目来说是不错的选择，但性能和微优化不是 Alex 所必需的。我自己也使用它们。总的来说，我认为我们正在进入功能/程序做事方式的时代。中间件、承载功能等的时代。纯粹、可重用和低耦合的实现。