我说过对于FXXX 不在公开场所将其同 Zend Framework 比较的这样的话。所以我在这里做一些补充说明，一些是关于技术的，一些是关于技术人员应有的技术涵养的。
在收到性能测试的反馈之后，我特别进行了测试：
在 include(‘FXXX.php’) 之前定义：
define(‘NO_LEGACY_FXXXPHP’, true);
则 FxxxPHP 只会载入两个文件：FXXX.php （核心）和 Config/DEBUG_MODE_CONFIG.php（默认的设置文件，用于调试模式）。而不会再载入 Compatibility.php 文件。此时，开发者按照 FxxxPHP 1.0.70 的规范编写应用程序即可。而 Compatibility.php 是为了方便 FxxxPHP 1.0.60 应用程序升级而设置的。
于是，我将这个开关加到之前的测试之上。很遗憾，在50次测试中，只有两次 FXXX 比 Zend Framework 快。
据说，在 L 兄的测试中通过修改了两行多余的代码，使得 FXXX 的执行快过了 Zend Framework。我没有办法测试，因为他并没有给出这个修改方法。不过我想也有可能的，因为框架本身在 loadClass 上的工作几乎完全相同。那么通过优化是完全可以得到相同的效能。
以下与技术无关：
L 兄关于非技术的问题解释了很多。我也补充一些吧。关于数据库和企业级应用，本来是没有必然的关系的。再说了，之前的讨论也是 L 兄首先提出 Zend Framework 应用在企业级开发。不知道后来怎么就改口了呢？
“ Zend.com 想把 ZF 打造成一个 All in one 的开发框架，最终变成 PHP 开发领域的标准。所以 ZF 中的东西越来越多，但许多其他框架已经做得很不错的设计和实现，ZF 却没有。这就是典型的贪多嚼不烂。”
这算不算误导大家呢？提出 All in one，提出企业应用的目的，然后等着后面有人说出“Zendframwork 就是为PHP企业级应用做准备的。”就立刻敲上一棍。这样不太好吧。
另外，关于 Zend Framework 的软肋， L 兄似乎没有找到哦。其实很多的，最简单的软肋，Zend_Db 现在还不支持 DSN 的 charset 功能。软肋戳到了么？没有吧？且不说我有没有激动，这软肋都戳到屁股上去了（比如性能、效率的问题）这还说个啥劲啊？
什么大而全，既然都是极小核心加外部扩展，那多一个功能，说明功能就强大一级，少一个功能，就少一个比拼的地方。这又作何解释？
最后呢，说一说做技术的人应该怎么做人。我从头到尾，除了指出 FXXX 在数据库上的不足，略有不灵活外，还有说过 FXXX 哪里不好？我一直都首先强调，FXXX 是非常优秀的。偷换概念，转义话题的行为，我就不一句一句点出来。不知道是谁把话题转移到“什么叫做企业应用”这个上面来的？是我么？好像不是。那是哪位高人呢？呵呵……
我欲成风归去，又恐琼楼玉宇……
Leave a Reply