PHP毫无疑问是当前比较流行的web开发语言，特别在构建小型应用时灵活快捷方便的特点更是令人满意。但是，当面对大中型应用时，PHP就表现得越来越力不从心了，无论是开发效率还是运行效率层面上，大中型应用还是Java更加理想。后来，经过实践的检验，发现把PHP从大中型应用中对立来看并不合适。与Java和C#这些编译型的语言相比，PHP的性能效率尤显不足，但是在前端展示层面上，PHP依然有着可以比较的优势，那就是她轻快灵活，可移植性好。总体而言，PHP在门户展示，产品展示，信息展示等前端界面的应用依然是受相当多用户的欢迎。

自看到PHP第一面开始就一直保持关注。PHP的受欢迎不是虚言，业界有着丰富的各种PHP系统和框架应用，我们随处可见的框架有Yii,ThinkPHP,Laravel,CakePHP,ZendFramwork,Symfony,CodeIgniter等等，而基于这些框架的CMS内容管理系统更是遍地开花，作为一个PHP爱好者，基于对PHP已有的认知，所有的框架不过是对PHP的重新包装，其底层的PHP基础完全没有变化，所有这些框架都没有基础的创新，于是，与其去学习这么多PHP框架，不如我自己写一个框架，用我自己的想法去包装PHP，按自己的意愿去完成各种框架所实现的功能，于是写Helper的动机就出现了。

Helper，名字不是很亮眼，但是很直观，就是一个助手的意思。作者的意图很简单，通过对PHP的高效封装，实现中小型应用的高效快速开发，解决以前不用框架时的繁琐和低效（当然，如果你精通前面提到的任意一款框架，也能达到相同的目的）。并且，PHP入门简单是人尽皆知的，一个刚毕业的大学生可以自学PHP，并立刻投入开发，那么，写一个PHP框架又能有多大的困难呢？

现实跟理想有点出入！！！

上网查找了一遍框架的实现原理，绝大部分都是通过Apache的UrlRewrite模块通过路由分发来实现的，据说还有通过404重定向来实现路由分发的(无奇不有)。Helper最后决定采用普遍的做法，使用UrlRewrite模块来实现。重定向将请求路径以参数的形式发送到入口文件-根目录下的index.php来处理，剩下的工作就是根据请求路径的分析来确定分发的路径。框架实现的第一步：写一个请求分发路由器！

刚开始并没有严格按照MVC的思想来设计，只要能将请求分发到指定处理的文件，即可完成请求，未必需要按照MVC的思想来照搬。实践证明，这种想法是可行的。所以，第一版本的Helper是PHP代码和HTML代码大量混合的模式，虽然看着很难受，但是起码可以正常执行了。接下来到数据库访问类的封装。原计划设想按照MyBatis思想进行设计：在配置文件配置好SQL，然后设计一套方法向这些语句传递参数，组装完成的SQL执行。后来一想，这种设计方式等同于让开发人员直接去编写原生的SQL语句来执行了，如同没有封装，遂放弃。后来第一版采用了非常无聊的普通封装：设计方法，传递sql需要的参数进行sql的组装。刚开始只是简单封装了where()、delete()、update()、save()方法，并且这些方法具有严重缺陷：无法指定主键条件。例如：save($obj)，要更新的数据行使用$obj的第一个属性值来识别，即是说，如果第一个传递的不是Iid唯一识别ID，那么该方法根本无法识别要保存的是哪一行。

事实很残酷，遇到的困难还有以下这些：1，设计__autoload()时导致类查找效率低下，重复加载，或者找不到对应类或者查找目录太多等。2，模板和母版怎么进行高效组装。3，缓存怎么设计（缓存的有效期，更新机制，缓存的种类，如何规避缓存击穿）。4，怎么设计有效的日志记录模块（无论是开发调试还是部署上线，日志都是非常必要的）。5，网站的开发和上线配置怎么设计能够兼容2种环境上下文。6，请求周期的异常处理机制。7，请求过程中的权限认证机制怎么设计。8，数据从数据库查询出来之后如何封装，让开发用户能用最优雅的方式调用。9，PHP连接mysql过程中出现频繁打开和关闭数据库连接的情况怎么处理(单例模式)。10，在Windows下开发，部署到Linux上时，出现各种系统不兼容的问题，比如大小写敏感问题。

坚持不懈地努力！！

上面提到的问题，经过精心地思考，一个一个地解决了，但是有些问题直到今天，仍然未能找到完美解决方案。可是当大部分问题得到解决时，Helper的雏形就出现了。最后采用的MVC设计思想和命名空间等这些思想的运用为问题的解决作出了极好的贡献。

未来Helper的路还有很长，但是至少Helper已经勇敢迈出去了艰难的第一步，未来可期，期待有您的加入！！！