mvc是一种设计思想,是一种设计模式。这个应该没错,但是任何一个框架的卖点绝不是因为他是遵循mvc模式开发的。而是因为它实打实地提供某类问题的快速解决方案。你使用它是因为你有这样的需求它能给你带来便利。
但凡某个mvc框架的介绍基本都是这样的,xx是一个用来解决xx问题的mvc框架,你应该可以看出,重点是能解决什么,而不是后面附带的mvc框架。
框架就好比给程序员使用的产品,一个产品如果不是针对某类具体问题而生的,那么这个产品的意义就不好说了。如果你仅把mvc当作一个产品,那么就好比你的产品什么都能做,但是什么都做不好,谁都不需要这类产品。
接下来说说引入一个框架可能产生的问题:
性能损失:但凡框架都会带来性能损失,这也是一些对性能要求很高的项目往往不会使用框架,而为自己的场景定制优化。当然这个性能在如今来说大概也可以忽略了。
复杂度提升:学习成本和部署成本这就是你必然要面对的问题。
适应性:框架一旦引入,你的整体结构就被固定死了,你需要按照固定的模式去使用,这个地方加一些自己写的具体代码,另外一个地方加一点,这些都是框架帮你规定好了的。这东西可能其实也挺好,方便你后续维护什么的,但是你得去适应。
摩擦:这个东西就不好说了,有些框架有些地方可能非常符合你的需求,有些地方却不是你想要的,甚至是反向的。这个时候你要么就去hack一下,要么就去修改一下该框架的源代码。总之你使用起来不会特别爽。
说了框架说说php语言本身。作为一门易学习使用,大量函数内置的这么一门语言。你发现你很多操作都不需要自己封装实现,内置的都已经足够强大了。
以前在深受mvc熏陶下,我用php写东西会这样,首先建立module,view,server3个目录,然后按照这种思路去填充对应的代码。这算不算一种mvc的简易实现了?
所以个人觉得php内置的强大可能导致更少的使用框架。一个框架不能过于抽象,也不能太具化。对php来说这点就很难把握。有时候你应该想想你需要的是一些php代码片段还是一个框架。
总的来说,每种开源的项目都是作者将其工作的沉淀和技巧的积累放出来供他人使用,期望得到他人的贡献,众人拾柴火焰高,目前github上的很多项目都是如此,有了这些项目,后来者的工作可以说是站在巨人的肩上。TG:li9047