开发自己的PHP MVC框架（如codeigniter）应该知道什么

一位面试官问了我一个有趣的问题：“如果我让你创建自己的MVC框架，你应该知道什么？”。除了以前端控制器为基础并相应地重定向我们的请求之外，我几乎无法对这一点给出具体的答案。如果有人能解释一下，我会很高兴。

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

我会回答这样一个问题：

你怎么会认为从头开始构建MVC框架可以解决你的问题呢？

MVC模式有很多优点，但也有很多缺点。 在PHP的发展过程中，几年前我们向自己介绍了MVC框架的时代，这非常棒！更快更容易的开发过程，大量的魔术，活动记录等

随着PHP社区的发展，我们现在正在艰难地学习过去的错误。极高的耦合性、边缘案例继承、全局性的使用以及打破每一条坚实规则的实现。MVC被框架滥用，它们的实现方式根本上是错误的！ 中间件的概念将是MVC框架衰落后留下的唯一继承

---

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

我想这个问题最简单的答案应该是准确地解释什么是PHP mvc框架，它的作用和好处是什么，比如谈论您在框架中偶尔使用的所有

类
，没有它您就无法工作：


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

并简要描述每种方法的用法，并讨论数据库类：


数据库配置
联系
查询生成器
等等

可能会谈论
加载程序
，
库
，
助手
等等
你的答案应该是：


基于MVC的应用程序尊重这一原则。第一个分离：UI逻辑与业务逻辑（“M”组件）。第二个分离（与UI逻辑相关）：用户请求调度逻辑（“C”组件）与表示逻辑（“V”组件）
“M”组件不知道任何其他应用程序组件，并且以这样的方式实现，即它可以由多个应用程序（甚至是不同类型的应用程序）共享
每个组件都可以用不同的方式建模和实现。这里可以讨论，这取决于需求，应该使用哪些对象以及它们应该如何相互作用。。。换句话说，这是你“很难给出具体答案”的部分。下面是一个示例，展示了我选择的使用MVC的web应用程序工作流方法
MVC模式（使用MVC模式开发应用程序）的优点：组件的可重用性、良好的可测试性、基于开发人员的专业化可以轻松地对某个组件执行更改。通过查看/阅读本答案末尾发布的第一篇参考资料，可以发现其他优势
至于缺点：增加了复杂性（就我个人而言，我没有看到其他的）
，等等

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

下面是我选择的使用MVC的web应用程序工作流方法的概述——主要受Robert Martin的演示启发，并试图尊重1979年提出的原始MVC模式的工作流（例如，控制器更新模型，视图从中提取数据，而不考虑控制器）

你可以在我的这篇文章中读到关于每个组件的更多细节




一些资源：










这可能不是一个“我有x个问题，超出了目前市场上任何MVC的范围，因此我必须构建自己的MVC”，而是一个“你真的了解MVC是如何工作的吗？通过告诉我一些核心方法来说明这一点（如果你想要每种方法，请包括优缺点）。。。我忘了是谁说的，但真正的精通是能够理解一些足以简单解释的东西，我认为这就是这里的目标。谢谢你的评论@Alex！事实上，在再读一遍这个问题之后，我认为你是对的。我想保留我的答案，因为在我看来，当你解释第一个问题时，如果有人能洞察我对它的看法，我会觉得很好。如果我可以，Chrysovalantis，我不同意你的说法“MVC从根本上是错误的”。分离关注点是正确的做法。因此，使用MVC模式基本上是正确的。尽管如此，基于MVC的各种应用程序（也可以是web框架）可能会被错误地实现。在我看来，您所说的最大的缺点是这些实现的影响，而不是MVC模式的影响。至于中间件，在我看来，它们要么只是MVC“C”组件的替代品，要么是它的补充。MVC的“V”和“M”部分保持不变。哦，是的，我也不同意这一部分。mvc是解决方案，而不是问题。但是codeigniter是mvc“错误”类型的一个很好的例子。然而，在国际海事组织，这是适合小规模应用。好捕获！我是说?