好奇 MVC 运作方式？

Question

这几日因为频繁的在网上看 ＭＶＣ (PHP) 和亲自实作了一些脚本，还有看Laravel
发现ＭＶＣ都是一个文件中会去找许多的ＦＵＮＣＴＩＯＮ
然后甚至ＦＵＮＣＴＩＯＮ再去找ＦＵＮＣＴＩＯＮ
这跟写在同一个页面有哪些差别？
难道这样速度不会变慢吗？

因为这样当它读取了这个ＦＵＮＣＴＩＯＮ脚本时（一开始的ＲＯＵＴＥＲ）
然后透过这个ＲＯＵＴＥＲ再去找第二个甚至后面好几个ＦＵＮＣＴＩＯＮ
这样它不就是会一直去找其他脚本然后最后再ＲＥＴＵＲＮ回来
还是说其实这样速度才会快？

所以宁愿是几十几百个文件，但是每个文件里面的脚本只有十几行、几十行
但若要完成某一个购物车功能他可能会 autoload 十几个文件里面的ＦＵＮＣＴＩＯＮ，最后每个ＦＵＮＣＴＩＯＮ 它们ＲＥＴＵＲＮ回来才会变成一个完整购物车（包含ＶＩＥＷ）
用这样来细分，这样执行速度反而比较快吗？

Answer 1

简单来说，引入MVC相当于一种最佳实践，它的目的并不是快，而是要给业务做梳理建模和角色分解，约定不同的关注点，也有利于面向对象的设计。就像低级语言和高级语言的关系，理论上前者（直接写汇编或机器码）有可能更快，后者通过编译会浪费一部分性能，但是高级语言大大拓宽了开发的想象力，以前可能大佬坐个飞机才写出来的程序，现在找十个光头码农也写的出来，原因就在于高级语言将聚焦点更多的放在了程序逻辑而不是硬件限制上（这就解放了生产力）。同样的MVC模型做的也是这个事，它是将控制器、模型和视图相互分离，代表了最基础的分层思想，是解决复杂问题的一个经典策略（IT领域里有很多分层策略的体现，比如OSI的7层模型和TCP/IP协议栈的4层模型就是典型个例）；另外它其实也是一种约定，即任何遵从MVC模型（可能用了框架也可能没用）搭起来的程序，你只要按照“从 控制器 获得用户输入，控制 模型 变更，并引发 视图 更新”这个流程找下去，就能大致理解程序的主要工作逻辑，所以相比大段大段的Function，MVC在组织大型程序上会更有优势，这就是为什么要用它的理由。