PHP框架发展存四误区 死穴不除难成大器

随着PHP技术的普及，PHP各类应用框架也如雨后春笋般飞快的发展，与之相矛盾的是，一些所谓的高手经常把自己写的一个"框架"作为一个产品，实际生产行为中往往使用某些CMS或论坛程序作为核心开发真正的应用。

其实框架这概念，最早来源于C/S软件的应用，比较经典的有：微软的MFC、Java的Spring、Struts、Hibernate（也就是所谓的SSH）之类的框架，当然MFC纯粹是针对C/S类应用的，而后者针对或适用于Web应用，然而不管是那种，应用在Web上，都是有明显缺点的，但PHP一些框架往往都继承了这些思想，所以到目前为止，PHP类框架还都是止于模仿，当然也确实充分利用了PHP的一些特性，但真正在应用上，仍然显得做大项目不足，小项目多余的感觉，这也是PHP框架一般只作为"学者"使用，应用却并不是那么流行，很多所谓的高手也宁愿自己去写一个框架的原因。

那么，PHP框架发展到底存在哪些误区呢？

主要有下面几个方面：

1、把控制器写得过于强大，从而偏离了框架的本质

有些框架的控制器简直可以完全代替rewrite了，但是这样有意义么？完全就是一个无聊的闹剧而已，作为框架，最需要做的事情一是要简便易用，二是提供多一些针对Web真正实用、稳定、必要的库，（而实际当中，系统类库和业务类库往往是不同的）做过多年程序员的人都知道，老手和新手的区别在于，老手通常是有很多即时可用的代码，而新手往往要自己去找，如果框架不能让新手、老手都一样简便实现某功能，那么要框架来干吗？所以说，过分去弄控制器这一块，就偏离了原则，并且可能对开发造成一定的麻烦。

2、思想上仍然按照Java的那种老的一套思路，更适合于开发B/S应用的企业管理软件，而与Web的思路有点偏离

就拿权限与模块化思路来说，一般的框架都把app固定死了，而实际应用中，Web的APP通常是有三重的，具体为：administrator后台管理应用池，member 前台会员控制中心应用池，public公众浏览信息应用池。

传统的框架虽然有通过权限系统进行隔离，但却通常是把administrator、member、public三块应用都混在一块，没有对安全级别进行隔离，不管是思想上，还是对于安全管理，其实都是不利的，就拿传统的论坛程序来说，通常管理员要登录后台，都必须要重新输入一次密码，其实这样做对安全确实是有利的，但从抽像思维来看，这是对管理员的应用进行了分离，姑且把这些应用当作"池"的概念，因此不能用传统的B/S企业管理软件的思想去设计。

3、View的模式过于死板，很难用于商业应用

这里说的商业用户是指要向第三方发布的应用，就拿CakePHP来说，因为视图固定得太死，如果想设计成真正易于美工修改，又支持多模板模式的，那几乎是要完全抛弃它原有的view机制，很多东西太过学术化，而与实际应用有点出入，加上模板引擎的思想大家很难真正做到统一，从而使PHP框架全面混乱。（由于每个人的理解有偏差，所以出现这样的问题也是在所难免的）。

4、框架本身过于庞大，导致实际开发中，很多人对框架进行不同程度的精简，从而严重不统一

就拿官方的ZendFramework来说，其实一些核心文件加载时间就要0.05秒以上，用这种东西，假如要做一些高性能的系统，几乎是不可能的事情，但是在国外，因为对知识产品权比较尊重，所以未经授权是不会胡乱改人的系统的，因为此应之就出现了不少用于提升PHP运行性能的东西，但这终究不是最了的解决方法的。