讨论贴：主流框架zend,ci和cake等之比较（用过框架的进，谈谈感觉）

[fxs_2008]

框架，用还是不用？ 用哪个？ 实在是一件纠结的事。

个人或多或少接触过zend,ci和cake框架。 虽然没有太多的深入，但也了解了一些方面和思想。

但如果你喜欢php的自由，用了那些框架，你的php还是php吗？

最近又看了一下zend.感觉还是比较难的。 没有项目实例。 手册不全。想做出一个用户验证都不好做（会的朋友提示一下啊）！而且zend到处使用设计模式，感觉像是java程序员在做。 所以，如果你的领导是学java的，很可能就选它了。 另一个感觉是zend可能是自已培训收钱。 但对于一个开源东西，如果足够复杂。谁还会用它。


相反，如果是中国用户，ci（codeigniter)可能是首选。ci的流程更符中国的传统思想。代码简易懂。 可它的核心里竟然没有layout. 只能自已加上。


cakephp就不说了。仿的是rails. (rails里的许多思想影响了几乎所有web领域框架的开发, 可以说至今可能仍无人能超越,如果你开发的不是高性能高流量网站，建议还是学他一下，国内的javaeye.com,iteye.com). 由于没有常驻内存对象,cake必须不断地查询表字段然后生成对象。 另一个，当有多个表关联时，它们之间的关系和定义是复杂的。

如果它都不能让你满意，该怎么办？

如果你想开发一个高性能高流量的网站？你会选哪个？ --->国内discuz的框架相对简单。典型的如ucenter. 直接使用mysql，没有各种各样的db接口。 一个核心类作为注册品。

也可能如老大所说的，还是要自已形成自已的框架？

[xuzuning]

对，还是说实际的实在。
不好意思英文盲，好多名词理解不深。
搜索了一下 layout 应该译做 布局 对吧？
所谓的布局就是允许使用者将各种相似或非相似的部件以代码或非代码方式置于画面中期望的位置上，而每个部件间是互不干扰的。
如果是这个意思的话，至少有一半的模板引擎是具备这样的功能的

不知道理解的是否正确，待确认后再继续说

[骄傲青蛙]

（控制器Controller）- 负责转发请求，对请求进行处理。
（视图View） - 界面设计人员进行图形界面设计。
（模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

你说该如何对应

===============================

View 就是各种各样的终端输出， 不管是图形界面， 还是单纯的字节流， 还是什么， 只要移动终端能支持的有效显示输出


Model 就是服务器提供的服务功能块， 这个服务可以是数据运算， 数据存储， 等等。


你一个View可以对应多个Model, 多个Model可以对应多个View, 怎么对都行， 只要定义没错、

[fxs_2008]

zend 的layout和rails的基本相同。

class xxController {
function init () {


}

function indexAction () {

}


}

layout的用法很简单，但实现有难度。 第一，它可以指定默认layout用哪个view文件， 如控制器初始化时；
第二，他可以在控制器初始化或action方法指定disable layout，也可指定另一个layout，盖住以前指定的。
第三，其本上，他先解析其他view.最后解析layout； 第四，任何view文件中均可指定layout的需要的一些变量参数，如layout中的meta信息。

[fxs_2008]

继续抱怨了。

zend中的db好象没有默认的单例。 每个表都要实例化。 这显然与php的特点不符的。手册中大量使用factory模式， 这显然高性能开发中应是问题的，用过的提示一个这个问题的解决办法？

[xuzuning]

这就是说，我的理解基本上是正确的了

如果是“先解析其他view.最后解析layout”，那么在实现上的确是有难度的，尤其是“任何view文件中均可指定layout的需要的一些变量参数”。你需要面对太多未知的东西，还要去规划他们

这就是我使用也不深入研究框架的原因。所以我采取了一种不同的做法，当然也是基于MVC的
一般的说 MVC 中的 M 是核心，他决定展示什么，然后是 V 怎么展示
而在我的系统中(还是称作工具箱比较好)，核心是 V 展示什么，然后是 M 构造需要的信息
这样一来，我就不需要去预判我可能需要什么了。一切的需求都在解析 view 时产生

[michaelzhouh]

我最近开始用ci了，Codeigniter我觉得很小巧，又很强大，又好扩展。

工欲善其事必先利其器，借助与一个好的框架，可以省很多事情，再不断的累积经验。

[fxs_2008]

[Quote=引用 50 楼 xuzuning 的回复:]

这就是说，我的理解基本上是正确的了

如果是“先解析其他view.最后解析layout”，那么在实现上的确是有难度的，尤其是“任何view文件中均可指定layout的需要的一些变量参数”。你需要面对太多未知的东西，还要去规划他们

这就是我使用也不深入研究框架的原因。所以我采取了一种不同的做法，当然也是基于MVC的
一般的说 MVC 中的 M 是核心，他决定展示什么，然后是 V 怎么展……
[/Quote]

是的,layout的思想其实是方便维护，因为只要一指定layout，相关模块布局就变了。 uc, thinkphp, ci都没有这个功能。 他们基本上还是php的老路. uc和thinkphp只要执行display()，可能就解析。 ci原理差不多了。

每个页，都要include（'header.php') , include("footer.php").

zend 和cakephp 均应学习的rails.

[fxs_2008]

ci和uc,thinkphp的原理还是有些不同的。thinkphp是解析模板。 ci和zend是缓冲区级数。

[Quote=引用 51 楼 michaelzhouh 的回复:]

我最近开始用ci了，Codeigniter我觉得很小巧，又很强大，又好扩展。

工欲善其事必先利其器，借助与一个好的框架，可以省很多事情，再不断的累积经验。
[/Quote]

Ci因为简单，开发效率可能要比zend高出1-3倍以上。 但ci以前还有一个缺点：命令行，以前是不支持的。现在可能有了。 这个功能一是开发；二是后台执行批处理时要用这个。

[amani11]

[Quote=引用 50 楼 xuzuning 的回复:]

这就是说，我的理解基本上是正确的了

如果是“先解析其他view.最后解析layout”，那么在实现上的确是有难度的，尤其是“任何view文件中均可指定layout的需要的一些变量参数”。你需要面对太多未知的东西，还要去规划他们

这就是我使用也不深入研究框架的原因。所以我采取了一种不同的做法，当然也是基于MVC的
一般的说 MVC 中的 M 是核心，他决定展示什么，然后是 V 怎么展……
[/Quote]

目前应用的框架思想有点类似这个意思，，，

在需要的地方，决定调用哪些M，若非需要，不载入无关文件

除了效率，还有好处是，避开了类似smarty的到处->assign……，个人比较反感这种框架赋值方式

[qidizi]

[Quote=引用 53 楼 fxs_2008 的回复:]

ci和uc,thinkphp的原理还是有些不同的。thinkphp是解析模板。 ci和zend是缓冲区级数。

引用 51 楼 michaelzhouh 的回复:

我最近开始用ci了，Codeigniter我觉得很小巧，又很强大，又好扩展。

工欲善其事必先利其器，借助与一个好的框架，可以省很多事情，再不断的累积经验。


Ci因为简单，开发效率可能要比zend高出1-3倍以……
[/Quote]

ci是支持命令行的.
<?php
//配置参数
$stop = 0;//1停止自动发送,0允许自动发送,用于调试时设定,而不必修改linux任务
$maxLetters = 100;//运行一次发送件数

//处理语句
if ($stop) exit('queue is pause,edit cmd.php setting!');
$_SERVER["REQUEST_URI"] = 'home/queue/index/' .$maxLetters;
include('index.php');
如果你需要接受命令行参数看一下args,好像是这个变量.

[qidizi]

[Quote=引用 54 楼 amani11 的回复:]

引用 50 楼 xuzuning 的回复:

这就是说，我的理解基本上是正确的了

如果是“先解析其他view.最后解析layout”，那么在实现上的确是有难度的，尤其是“任何view文件中均可指定layout的需要的一些变量参数”。你需要面对太多未知的东西，还要去规划他们

这就是我使用也不深入研究框架的原因。所以我采取了一种不同的做法，当然也是基于MVC的
一般的说 MVC 中……
[/Quote]

某种情况隔离其实是好事.你想想,如果你把模板交给非php人员修改.而你又不想让它随便把php代码用到的变量都输出时,而非你限定的

[fxs_2008]

[Quote=引用 56 楼 qidizi 的回复:]

引用 54 楼 amani11 的回复:

引用 50 楼 xuzuning 的回复:

这就是说，我的理解基本上是正确的了

如果是“先解析其他view.最后解析layout”，那么在实现上的确是有难度的，尤其是“任何view文件中均可指定layout的需要的一些变量参数”。你需要面对太多未知的东西，还要去规划他们

这就是我使用也不深入研究框架的原因。所以我采取了一种不同的做……
[/Quote]

这个隔离好象CI不支持吧！ ucenter的好象的模板解析不只支持不支持隔离，smart模板算是 隔离吧。

在强调效率的今天，隔离估计很少有做了。 如果那个UI懂php，也是挡不住的。

[深圳张弓]

要使用什么框架，得看项目大小、性质而定：
因我个人从业时间长，不管是.net的框架、delphi的框架、java的框架，php的框架，业界内各类知名的框架或多或少都有接触及使用过，所以凑个热闹也来说几句，我的感觉是：每一个框架都有其应用范围或适合的产品类别：

对于一个小不点项目且基本上不需要做什么升级的，用Zend是有些浪费时间，比如这几天我委外了一个目标非常明确的小php项目，委外人员做了好多天到现在还没有完工，但若不用框架最多3天就做完了，这算是框架中毒了。

若是小团队或个人作品，建议使用业界成熟框架，这样可以节约你很多时间。而有一定规模的团队在有条件时，建议开发自己的框架，虽然自己开发框架初期会很稚嫩，且大多数也是在参考或模仿别人的框架，但这种自己开发的框架，将不会给公司的发展带来任何阻碍。

一已之见，求板砖！

[fxs_2008]

[Quote=引用 58 楼 cerc2477 的回复:]

要使用什么框架，得看项目大小、性质而定：
因我个人从业时间长，不管是.net的框架、delphi的框架、java的框架，php的框架，业界内各类知名的框架或多或少都有接触及使用过，所以凑个热闹也来说几句，我的感觉是：每一个框架都有其应用范围或适合的产品类别：

对于一个小不点项目且基本上不需要做什么升级的，用Zend是有些浪费时间，比如这几天我委外了一个目标非常明确的小php项目，委外人员……
[/Quote]
同感

[fxs_2008]

说真的，zend的 model及表操作，真不是人干的活，远没有直接表操作来的快。如果不是要所谓的对象安全性外，没有必要的。 还有数据库pdo，如果不是要数据库兼容外，也没有必要

zend 的form类也是问题，有人称之为鸡肋。 表单验证不可少， 但如何简易，是个问题。

用zend不就是用类库吗？ 而且手册不详。 远没有其他框架清楚。

[daswcszxw]

我是个初学者。
木有用过框架。
都是自己研究。

[lala5201]

我觉得tp中的orm在多表查询时很难用啊，还要建一个model,如果连表多的话，很麻烦。而且就算是相同的两个表连，可能要取出的字段不一样。

[fxs_2008]

[Quote=引用 62 楼 lala5201 的回复:]

我觉得tp中的orm在多表查询时很难用啊，还要建一个model,如果连表多的话，很麻烦。而且就算是相同的两个表连，可能要取出的字段不一样。
[/Quote]

所有不直接查的框架都有要这个问题。　连表查询真不知直接查方便！　一般的处理是拆开成单个查询。
zend view的占位符要先定义再使用，远不如rails的方便。　

[xuzuning]

用 php 去实现 ORM 真所谓“画虎画皮难画骨”，形似而神不是

[josph2012]

占座，占座了。有时间 去拜读各框架的源代码。暂时不用框架 。