|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-02-12
wisdomwang 写道 有没有兄弟研究过ECMALL的代码？
它的MVC基础代码感觉还不错，比起ZF，能提高不少效率，就是不知是康盛自己做的还是基于某个现成的框架。 整个ecmall我都读完了，当时一个项目用的就是ecmall。他的model写的还不错。不过里面有一些恶习和妥协。对他的ajax库尤为痛恨。 |
| 返回顶楼 | |
|
发表时间：2009-02-13
php框架还是越简单越好
|
| 返回顶楼 | |
|
发表时间：2009-02-14
最后修改：2009-02-14
看了一下 dualface 的 QeePHP，感觉真象 ROR 一个模子刻出来的。
但也有自己的特色的地方，我建议QeePHP完善一下生成工具 |
| 返回顶楼 | |
|
发表时间：2009-02-14
fnet 写道 看了一下 dualface 的 QeePHP，感觉真象 ROR 一个模子刻出来的。
但也有自己的特色的地方，我建议QeePHP完善一下生成工具 这个是一个重点，完善基于 Web 的代码生成工具和维护工具。当然命令行的也会有，呵呵。 |
| 返回顶楼 | |
|
发表时间：2009-02-17
我是很不屑用框架的，太庞大，很影响效率。
|
| 返回顶楼 | |
|
发表时间：2009-02-17
robbin 写道 1、PHP极难出现严重的内存泄露问题，随便你代码写的多烂，反正每个请求一执行完毕，所有资源统统释放光。而Python/Ruby则需要依赖GC来回收内存，因此稍有不慎，还是会出现GC无法释放的内存泄露问题。 这条总结的太棒了！ 不过这种看似极难出现的问题还是被我碰到过。 以前一个项目调试过程中是用JSI管理脚本的，开发期间跑几个小时Apache内存就跑到1g。 估计是PHP5的zip扩展好像还是会有泄露，不知道是不是我的用法不对。 http://jsi.googlecode.com/svn/trunk/JSI2/web/scripts/index.php |
| 返回顶楼 | |
|
发表时间：2009-02-17
jindw 写道 robbin 写道 1、PHP极难出现严重的内存泄露问题，随便你代码写的多烂，反正每个请求一执行完毕，所有资源统统释放光。而Python/Ruby则需要依赖GC来回收内存，因此稍有不慎，还是会出现GC无法释放的内存泄露问题。 这条总结的太棒了！ 不过这种看似极难出现的问题还是被我碰到过。 以前一个项目调试过程中是用JSI管理脚本的，开发期间跑几个小时Apache内存就跑到1g。 估计是PHP5的zip扩展好像还是会有泄露，不知道是不是我的用法不对。 http://jsi.googlecode.com/svn/trunk/JSI2/web/scripts/index.php php 从本质上来说，想要获得一个像样的功能，一定要膜拜 C。所以一般在 php 中遇到的内存泄漏都是由于 c 代码存在泄漏造成的。这和 php 代码编写造成泄漏是有本质区别的。 另外，php 的框架的繁荣是其想脱离其“草根性”，进入“企业开发俱乐部”。在大型应用环境中，总不能还严守作坊式开发的老路子，对吧？那么框架就成为规范开发、增加可维护性的一个必然途径。这个阶段其实 java 也有过吧？干过些年 java web 开发的人应该也写过那种混写的 jsp，甚至是混写的 sevlet。 还有，如果不从 php 的底层引擎着手改造，像什么连接池、持久化之类的东西，即便是在 php 中实现，也是一个奇怪的东西。但是如果从 php 的底层进行改造，那么 php 除了有一个近似于 c、java、perl 的语法外，同其他如 python 和 ruby 会有多大区别呢？没有特色的东西，更容易受到冲击，并被淘汰。 哦，对了，php 实际上起源于 perl。一些最古老的 CGI 的东西传承了下来，形成特色。这其实也挺好的。 “有口水的地方就有老廖，有老廖的地方就有口水”还真是至理名言，哈哈，开玩笑的，QeePHP 比 Flee 进步不少，继续加油吧。 |
| 返回顶楼 | |
|
发表时间：2009-02-17
绝对的精华帖！谢谢楼主和Robbin！
poshboytl 写道 robbin 写道 站在产品的层面来看，Python的CMS plone是最优秀的，功能非常强大，二次开发很容易，又没有drupal的性能问题。上海润普就用plone开发了好几个商业项目了，其中包括像上航的一些系统。
但问题是:即便在Python社区里面，高度产品化的zope/plone现在也渐渐不再是主流了，主流技术跑到了django那里去了。所以drupal这种反PHP理念的东西能有多大前途，我觉得很难说。 Robbin能不能谈谈, 高度产品化的zope/plone的"失败", 是因为zope/plone本身的"失败"? 还是"高度产品化"的失败? 很想听听你对这方面的看法. 因为我猜测也许rails社区也会出现这种"高度产品化"的东西. 我觉得应用（比如产品）和基础（比如框架）常常是交替发展的。因此不觉得产品化跟失败有必然联系。Robbin对drupal的前途存疑应该主要是它“反PHP理念”吧。 robbin 写道 其实PHP核心问题都不是性能，而是能不能保持“简单性”和“草根性”
一个有点编程背景的普通人，只需要学习PHP半天时间，就可以上手开始开发web应用了，这就是PHP最大的优势。专业程序群体才多大，而电脑爱好者的群体有多大？ 我一个朋友，做photoshop出身的，人家学了两天PHP，到处接活给人家开发网站，一个人全部搞定。你让他学Java,那真要了他的命了。我另外一个朋友的老公，人家压根就不是这一行的，照样会用PHP搭网站，人家上网去下载一个PHP程序，改吧改吧页面，就弄好了，你让人家学ruby？那肯定不可能。 PHP的人海战术也就是这么来的，群众基础好。事实上PHP5曾经在相当长时间内被抵制，就是因为PHP5的面向对象语法引入了对于电脑爱好者来说门槛开始变高了，PHP开始变复杂了。 因此PHP再用什么框架，是违背PHP本身的设计哲学的。PHP就应该做简单的页面处理就够了，复杂的逻辑让后台的Java/C++去处理。 很精辟。但这是我们javaer的想法，PHPer们未必肯甘于寂寞。 |
| 返回顶楼 | |
|
发表时间：2009-02-18
或与非 写道 绝对的精华帖！谢谢楼主和Robbin！
很精辟。但这是我们javaer的想法，PHPer们未必肯甘于寂寞。 作为一个 PHPer 我提供我的一些观点吧：http://www.mikespook.com/index.php/archives/286 对于 php 框架总结一句话就是“事物总是在它应该出现的地方出现，应该消失的地方消失。” |
| 返回顶楼 | |
|
发表时间：2009-02-18
看的晕头转向
表现层看重性能的能否举个例子？ 顺便加上后台设计或者平台设计? 如果有时间更好，总的运行时间，表现层时间，后台执行时间。 是否用框架，是否用PHP,JAVA,RAILS,c/c++，只能说谁用谁知道，没什么定论吧。 关键还是看怎么玩，谁玩。 |
| 返回顶楼 | |
