记得曾看过一个说法，说php是否应该使用框架进行开发是一个饱受争议的问题。对此我个人的看法是，框架的使用肯定是有必要的，只是看在开始项目时选择一个什么样的框架更好了。使用框架，绝对可以大大减少项目的代码量，用最少的代码来实现最多的功能，从而在缩短开发周期的同时大大增长程序猿的寿命，真可谓是一举多得。当然，任何事情都有其两面性，框架的实用最主要的一个问题个人人认为其就是在便利了编码的同时降低了性能。我们随后就会针对这些问题展开一些讨论。
我目前着手的一个项目就是Enterprise Framework，现在它托管在GitHub上，有兴趣的朋友可以看一看。它的出现正是因为我对于之前VMS所使用的Codon Framework和ANN所使用的ThinkPHP两框架均感觉不够满意，而进行的开发。对于Codon不用多说，其仅仅是作者Nabeel Shahzad针对VMS设计的专用框架，目录结构杂乱，代码冗杂，毫无语法性可言；而ThinkPHP作为国内一个屡获殊荣的开源项目，我衷心地说它是很成功的，从各个方面来看都是十分完美的，是汇集八方精英而完成的巨作。然而它最重要的一点就是性能代价过大，有些累赘了。让我们来看一些数据：ThinkPHP在调试模式下运行一次需包含130个文件左右，在部署模式已编译的情况下仍需要加载40个文件左右；调试模式下一次极简的运行内存开销都在1兆以上，对于一些建议的项目来说真的是小题大做了。
尽管对TP那庞大的躯壳我有些许的不认可，但不得不承认其理念是值得称赞的。它的常用方法，数据库操作和View层等都是用过一次就会爱上的特性。在稍前的8月，我为了简化繁琐的数据库操作模仿了TP中DB类的连贯操作写了一个数据库操作类——epdb，在早些的博文中我有提到。事实上之后我将其稍作修改后整合进了Enterprise Framework。
让我来谈一谈我心目中的一个适合小项目的php框架应该是什么样的：第一点它一定要有MVC架构，现在MVC几乎成了不成文的标准。其次它需要有TP一样便于使用的常用的特性——当然，仅仅是够用就好，无需使得代码过于冗杂。TP中的A/D/M/F/S/C等单字母方法与便捷的session/cookie操作在开发过程中的体验是极佳的，这点无需多说，用过TP的朋友应该都有很深刻的印象。第三，它需要一些可选类，即是运行时不是自动加载而是在开发的过程中按需手动导入的，这样在简便开发的过程中也不会因过多的包含操作造成性能的额外开销。说到类，这个框架还需能够很好地融入各种第三方类/类库，从而使得开发的过程更有弹性。
我为何常常纠结于ThinkPHP？它引入的特性太多了——MVC，CBD，RESTful等理念，Cluster引擎，Hybrid手机应用的配套ThinkPHP Mobile……我在写iANN的时候，时常会问自己：我们真的需要这么多东西吗？这只是一个小型项目啊！所以说到底来，衡量一个框架的好坏也许不能只是一味地从技术层面去考量，更需要注意的，可能是“技术——性能”这天平的平衡。
按道理来说我喜欢的是一气呵成的感觉，但由于种种原因本文是经由至少三次的中断而完成的，写作初期本还想融入更多内容，然而多次中断后已经失去了很多原有的想法，那么本文就此打住吧。
写到这里，我想起用php初期自己发过的一条状态，其呈现的是我因现在看来进一个简单的函数就能实现的过程却把当时的我折腾的绞尽脑汁。这很说明问题：时间是可以丰富人的。我想，也许在经历了几次Enterprise Framework的代码重构之后，那时的我也许会对本文有更多其他的看法吧。这篇文站完成后，我不会再对其进行任何修改，待到一年、两年甚至更多年后再来看，也许会发现，这是一笔无形的财富。
