首页 | 新闻 | 交流 | 问吧 | 文档 | 手册 | 下载 | 博客

收藏此问题 发表新评论

关于Zend_Db的几个问题 (请老王和老廖进)

技术问题,重新发帖讨论。

从二位之前的发言来看,感觉都对ZF了解不多,特别是老王同学,昨天才看了Zend_Db_Table,凭猜测来判断Zend_Db_Table是鸡肋。

二位的观点:
1。老廖:Zend_Db_Table不支持几种数据库关联,如一对一,一对多,多对多:
原话:“Zend_Db_Table_Relationships 也是个失败的设计。我们常见的四种数据关联(HAS ONE、HAS MANY、BELONGS TO、MANY TO MANY),它都不支持,仅仅是可以通过指定外键字段来进行 JOIN 查询。”

2。老廖&老王,Zend_Db_Table功能太弱,不支持Left join;
3。老王:Zend_Db_Select太丑陋,滥用OO。
4。Zend_Db_Rowset,Zend_Db_Row 为何不用数组

下面一一回复:

1。Zend_Db_Table不支持几种数据库关联,如一对一,一对多,多对多

这一点看法早已经过时了,ZF中用的是关联表,而不仅是外键来进行Join查询。
http://framework.zend.com/manual/en/zend.db.html#zend.db.adapter.example-database
http://framework.zend.com/manual/en/zend.db.table.relationships.html

2。Zend_Db_Table功能太弱,不支持Left join;

这一点也是你们自行猜测的吧? 搞技术的这样信口开河态度真是不对。

Zend_Db_Table在多对多查询时使用的是Zend_Db_Table_Row中的findManyToManyRowset()方法,现在是默认是使用join(INNER JOIN),但并不表示不支持left join。只要你自己继承一个Row类(比如MyRow),然后覆写一下findManyToManyRowset()方法就可以了,或者新增一个方法。
只需要把
复制PHP内容到剪贴板
PHP代码:
->join(array('m' => $matchName), $joinCond'*');

改为
复制PHP内容到剪贴板
PHP代码:
->joinLeft(array('m' => $matchName), $joinCond'*');

然后设置你的Table使用的Row类为你自己的Row
复制PHP内容到剪贴板
PHP代码:
$myTable->setRowClass('MyRow');

就OK了,这很简单吧。

3。Zend_Db_Select太丑陋,滥用OO。
这一点有点搞笑。 注意Zend_Db是要提供跨数据库支持的,现在来说这是唯一的途径。 老王自己也承认想不出更好的办法。 丑陋? 审美眼光不同吧。
使用Zend_Db_Select,将来就可以在迁移数据库时就舒服得多。而且现在Zend_Db_Select已经很强大了,用起来很顺手。

4。Zend_Db_Rowset,Zend_Db_Row 为何不用数组
这一点见仁见智,我就觉得一个OO的系统中把数据通过VO传递是很自然的事,以后如果需要,还可以使用对象缓存,放到内存里,提高效率,数组就没法进行缓存。

[ 本帖最后由 Haohappy 于 2007-8-16 14:36 编辑 ]
昵称: Haohappy  时间: 2007-08-16 14:30:00
很精彩, 请继续.
顺便说下, 楼主第4条的解释是个人理解吧? 对象缓存这样的东西在服务器端的应用应该不会太多, 毕竟内存有限. 现在一般是服务器生成XML+XSLT 再丢给browser去处理.
昵称: chill_gun  时间: 2007-08-16 14:54:00
喜欢这类的讨论…… :)
昵称: lnsoso  时间: 2007-08-16 15:03:00
我是所有的DB拿来用呢
看下我的
复制PHP内容到剪贴板
PHP代码:
class Goods extends Zend_Db_Table
{
    private  
$_request;
    public  
$pagurl;
    
    protected function 
_setup()
    {
        
$config Zend_Registry::get('config');
        
$this->_name $config->database->prcode.'goods';
        
$this->_request = new Zend_Controller_Request_Http();
        
parent::_setup();
    }    
    
/**
 * 单个商品信息
 */
    
public function oneview($id)
    {
        
$config Zend_Registry::get('config');
        
$table $config->database->prcode.'brand';
        
$sql "SELECT a.*,b.brandname,b.logo,b.id AS brandid FROM $this->_name a
            LEFT JOIN  $table b  ON a.brandid = brandid 
            WHERE a.id = '$id'"
;
        return 
$this->_db->fetchRow($sql);
    }
    
/**
      * 相关商品信息
      */
    
public function interfix($id)
    {
        
$where      $this->getAdapter()->quoteInto('issale=1 AND catid = ?',$id);
        return 
$this->fetchAll($where,'id DESC',5)->toArray();
    }
    
/**
      * 相关品牌商品信息
      */
    
public function brand($id,$_page=1,$nums=5,$link='?')
    {
        
$where      $this->getAdapter()->quoteInto('issale=1 AND brandid = ?',$id);
        
$total $this->fetchAll($where,'id DESC')->count();
        
$pager = new Pager($total,$nums,$_page);
        
$rowset $this->fetchAll($where,'id DESC',$nums,$pager->_offset());
        
$this->pagurl$pager->num_link($link);
        return 
$rowset->toArray();
    }
    
    
/*
     *推荐商品
    */
    
public function is_goods($act='is_best',$_page=1,$link='?',$nums=6)
    {
        
$where        $this->getAdapter()->quoteInto('issale= ?',1)
                      .
$this->getAdapter()->quoteInto(" AND $act = ?",1);
        
$total        $this->fetchAll($where)->count();
        
$pager        = new Pager($total,$nums,$_page);
        
$rowset       $this->fetchAll($where,'id DESC',$nums,$pager->_offset());
        
$this->pagurl $pager->num_link($link);
        return 
$rowset->toArray();
    }


昵称: xgwork  时间: 2007-08-16 15:44:00
Zend_Db_Table好难用呀..
昵称: ddjj123  时间: 2007-08-16 17:19:00
Zend_Db_Table 的确有些鸡肋。
新版本的Zend_Db_Table的确支持多重数据库关系,但是使用方法很复杂。

另外,Zend_Db_Table 每次都需要构造函数时候,执行一个统一的数据库语句(DESCRIBE TABLE)。有时候没有必要。
而且语句支持比较差,在更新数据和读取数据库方面扩展性不好。


Zend_Db_Select 是我很欣赏的类。
开始觉得很变扭;了解了,却发现没有更好的解决方法了。
利用Zend_Db_Select 可以扩展出很多便利的Sql语句。甚至包括select的嵌套等那种复杂的Sql。
我现在的项目的数据库select操作 就是根据Zend_Db_Select 做的扩展。
昵称: qqinxl  时间: 2007-08-16 17:58:00
引用:
关于Zend_Db的几个问题 (请老王和老廖进)

技术问题,重新发帖讨论。

从二位之前的发言来看,感觉都对ZF了解不多,特别是老王同学,昨天才看了Zend_Db_Table,凭猜测来判断Zend_Db_Table是鸡肋。

二位的观点:
1。老廖:Zend_Db_Table不支持几种数据库关联,如一对一,一对多,多对多:
原话:“Zend_Db_Table_Relationships 也是个失败的设计。我们常见的四种数据关联(HAS ONE、HAS MANY、BELONGS TO、MANY TO MANY),它都不支持,仅仅是可以通过指定外键字段来进行 JOIN 查询。”

2。老廖&老王,Zend_Db_Table功能太弱,不支持Left join;
3。老王:Zend_Db_Select太丑陋,滥用OO。
4。Zend_Db_Rowset,Zend_Db_Row 为何不用数组

下面一一回复:

1。Zend_Db_Table不支持几种数据库关联,如一对一,一对多,多对多

这一点看法早已经过时了,ZF中用的是关联表,而不仅是外键来进行Join查询。
http://framework.zend.com/manual ... er.example-database
http://framework.zend.com/manual ... .relationships.html
你贴的第一个数据库结构就是典型的数据表间的关联,你却说过时了,不知道你是指这种设计方法过时了还是“一对一”、“多对多”这种称呼方式过时了?

你贴的数据结果,几个表之间的关系如下:

bugs 有三个 belongs to 关联到 accounts 表,以及一个 many to many 关联到 products 表。
为了实现 many to many,所以多了一个 bugs_products 表。
引用:
2。Zend_Db_Table功能太弱,不支持Left join;

这一点也是你们自行猜测的吧? 搞技术的这样信口开河态度真是不对。

Zend_Db_Table在多对多查询时使用的是Zend_Db_Table_Row中的findManyToManyRowset()方法,现在是默认是使用join(INNER JOIN),但并不表示不支持left join。只要你自己继承一个Row类(比如MyRow),然后覆写一下findManyToManyRowset()方法就可以了,或者新增一个方法。
只需要把

[复制PHP代码] [ - ]
PHP代码如下:
->join(array('m' => $matchName), $joinCond, '*');


改为

[复制PHP代码] [ - ]
PHP代码如下:
->joinLeft(array('m' => $matchName), $joinCond, '*');

然后设置你的Table使用的Row类为你自己的Row

[复制PHP代码] [ - ]
PHP代码如下:
$myTable->setRowClass('MyRow');


就OK了,这很简单吧。
这点是我没表达清楚。我的意思是指应该在定义了关联的基础上自动生成包含 JOIN 的查询。当然这种自动化能力也要能禁用。
而像你上述的写法,只不过是把 SQL 语句换成了 PHP 写法而已。并没有根据定义来自动构造 SQL。
引用:
3。Zend_Db_Select太丑陋,滥用OO。
这一点有点搞笑。 注意Zend_Db是要提供跨数据库支持的,现在来说这是唯一的途径。 老王自己也承认想不出更好的办法。 丑陋? 审美眼光不同吧。
使用Zend_Db_Select,将来就可以在迁移数据库时就舒服得多。而且现在Zend_Db_Select已经很强大了,用起来很顺手。
呵呵,丑不丑陋倒无所谓,Db_Select 是 ZF 数据库部分主要的工具,没有也不行。
引用:
4。Zend_Db_Rowset,Zend_Db_Row 为何不用数组
这一点见仁见智,我就觉得一个OO的系统中把数据通过VO传递是很自然的事,以后如果需要,还可以使用对象缓存,放到内存里,提高效率,数组就没法进行缓存。
VO 这种东西最早来自 Java。现在 VO 在 Java 世界都是被批烂了的东西,PHP 还去捡过来。
至于使用对象可以缓存,放到内存中提高效率,我真的有点怀疑你是不是进行过测试!

前不久我回复了一个帖子,正好说到对象缓存的问题。

在 PHP 中,缓存对象的代价是极高的!

第一:如果不自己编写 __sleep() 和 __wakeup() 方法,对象只能序列化成字符串以后缓存;
第二:从序列换以后的字符串还原为对象时,必须先载入对象的定义文件

如果只是单纯的传递数据或者缓存数据,用 PHP 自带的数组绝对是最高效率的。

我在讨论 Row 时说,如果真的希望用对象来封装数据,最好把对数据操作的行为也封装到对象中。此时就是一个完整的 ActiveRecord 模式。单纯的用对象属性来代替数组传递数据,在 PHP 中没有任何意义。Java 中这样做,至少还可以通过对象属性来实现类型安全。
昵称: fleaphp  时间: 2007-08-16 20:02:00
引用:
我是所有的DB拿来用呢
看下我的
复制内容到剪贴板
代码:
class Goods extends Zend_Db_Table
{
    private  $_request;
    public  $pagurl;
   
    protected function _setup()
    {
        $config = Zend_Registry::get('config');
        $this->_name = $config->database->prcode.'goods';
        $this->_request = new Zend_Controller_Request_Http();
        parent::_setup();
    }   
    /**
* 单个商品信息
*/
    public function oneview($id)
    {
        $config = Zend_Registry::get('config');
        $table = $config->database->prcode.'brand';
        $sql = "SELECT a.*,b.brandname,b.logo,b.id AS brandid FROM $this->_name a
            LEFT JOIN  $table b  ON a.brandid = brandid
            WHERE a.id = '$id'";
        return $this->_db->fetchRow($sql);
    }
    /**
      * 相关商品信息
      */
    public function interfix($id)
    {
        $where      = $this->getAdapter()->quoteInto('issale=1 AND catid = ?',$id);
        return $this->fetchAll($where,'id DESC',5)->toArray();
    }
    /**
      * 相关品牌商品信息
      */
    public function brand($id,$_page=1,$nums=5,$link='?')
    {
        $where      = $this->getAdapter()->quoteInto('issale=1 AND brandid = ?',$id);
        $total = $this->fetchAll($where,'id DESC')->count();
        $pager = new Pager($total,$nums,$_page);
        $rowset = $this->fetchAll($where,'id DESC',$nums,$pager->_offset());
        $this->pagurl= $pager->num_link($link);
        return $rowset->toArray();
    }
   
    /*
     *推荐商品
    */
    public function is_goods($act='is_best',$_page=1,$link='?',$nums=6)
    {
        $where        = $this->getAdapter()->quoteInto('issale= ?',1)
                      .$this->getAdapter()->quoteInto(" AND $act = ?",1);
        $total        = $this->fetchAll($where)->count();
        $pager        = new Pager($total,$nums,$_page);
        $rowset       = $this->fetchAll($where,'id DESC',$nums,$pager->_offset());
        $this->pagurl = $pager->num_link($link);
        return $rowset->toArray();
    }
你没有贴数据结构,所以我只能猜测了。

goods 是商品表,而 brand 是品牌表,商品表有一个 brandid 字段,保存品牌id。

oneview() 查询指定的商品及其品牌信息
interfix() 查询指定类别已经售出的商品?
brand() 查询指定品牌最近售出的n个商品?
is_goods() 查询所有推荐的商品?

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

你如果觉得 Zend_Db_Table 很好用,那看看 FleaPHP 如何实现同等功能:
复制PHP内容到剪贴板
PHP代码:
class Goods extends FLEA_Db_TableDataGateway
{
    
// 数据表名称
    
public $tableName 'goods';
    
// 主键字段名
    
public $primaryKey 'id';

    
// 定义一个 belongs to 关联
    
public $belongsTo = array(
        
'tableClass' => 'Brands',
        
'foreignKey' => 'brandid',
        
'mappingName' => 'brand'
    
);

    public function 
oneview($id)
    {
        
// 事实上已经没必要单独写一个 oneview() 方法了
        
return $this->find($id);
    }

    public 
interfix($id)
    {
        
$id $this->dbo->qstr($id);
        return 
$this->findAll("issale = 1 AND catid = {$id}"'id DESC'5);
    }

    public 
brand($id$_page 1$nums 5$link '?')
    {
        
$id $this->dbo->qstr($id);
        
$c;
        
$limit = array($nums, ($_page 1) * $nums);
        return 
$this->findAll($conditions'id DESC'$limit);
    }

    public function 
is_goods($act='is_best',$_page=1,$link='?',$nums=6)
    {
        
$act $this->dbo->qstr($act);
        
$c;
        
$limit = array($nums, ($_page 1) * $nums);
        return 
$this->findAll($conditions'id DESC'$limit);
    }
}


上面代码没有任何 JOIN 之类的字样,因为在类的定义中已经把关联定义好了。FLEA_Db_TableDataGateway 会在查询、更新、删除、插入记录时根据情况自动处理关联的表。大家可以自行对比一下哪种更简单。

在定义了关联后,find()、findAll() 就会自动查询关联数据。所以后面的 is_goods() 等方法在查询商品信息时,也会把这些商品的品牌数据查询出来(当然也可以要求 TableDataGateway 不自动查询关联表)。对于开发者来说,这种自动化能力可以减少许多编码量,并且在数据库结构、数据表之间的关系发生变化时,也不用到处修改 SQL 语句。

[ 本帖最后由 fleaphp 于 2007-8-16 20:23 编辑 ]
昵称: fleaphp  时间: 2007-08-16 20:19:00
引用:
原帖由 <i>fleaphp</i> 于 2007-8-16 20:02 发表 <a href="http://www.phpchina.com/bbs/redirect.php?goto=findpost&pid=245690&ptid=33396" target="_blank"><img src="http://www.phpchina.com/bbs/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a><br />

<br />

<br />
你贴的第一个数据库结构就是典型的数据表间的关联,你却说过时了,不知道你是指这种设计方法过时了还是“一对一”、“多对多”这种称呼方式过时了?<br />
<br />
你贴的数据结果,几个表之间的关系如下:<br />
<br />
bugs 有 ...
<br />

搞笑。。。我是说你的看法过时了。   你不是说Zend_Db不支持数据表间的关联吗?  这不是瞎扯吗?
昵称: Haohappy  时间: 2007-08-16 20:59:00
来的晚了点,因为刚才一帮人去一个朝鲜族饭馆吃饭去了,不过大家都觉得不好吃。看来不同民族的人对待美食的看法有相当大的差距。

首先,我觉得haohappy的心态已经失衡了,是你在贴子题目中写的请我和老廖进来的。可以我发现老廖回帖之后,你竟冷冷的说老廖的话搞笑,胡扯。。。

下面我一次回答一下你的问题:

1。Zend_Db_Table不支持几种数据库关联,如一对一,一对多,多对多

php中对于各种表关系的实现已经有相当多的例子了,如果是基于表数据入口模式的,可以参考Fleaphp的实现,如果是基于行数据入口的,可以参考Cakephp的实现。Zend_Db_Table的实现相比较,很弱。

2。Zend_Db_Table功能太弱,不支持Left join。

你帖子里说可以用joinLeft,对于你的解释,我只能说我们思维方式有差异,我说的是单单的Zend_Db_Table,如果你这样回答,那Zend_Db_Table已经无所不能了,大不了我用Db_Select构造一个SQL就好了,但记住,我说的是Db_Table。

3。Zend_Db_Select太丑陋,滥用OO。

你帖子里说:“老王自己也承认想不出更好的办法。 ”,哥们,请你结合上下文语境再看看我的话。我这句是一个讽刺语句。。。。如果还没看懂,我给你举个更简单的例子。我说:中国队中场就得郑智上了,这不代表我认为郑智是多nb的人物,只是在中国队这群白痴中,实在没人了,只能让郑智上了。

4。Zend_Db_Rowset,Zend_Db_Row 为何不用数组

你帖子里说:“数组就没法进行缓存。”。我没法回答你这个问题了,无语。。

你帖子里说:“一个OO的系统中把数据通过VO传递是很自然的事”,大哥,干我们这行的一定要总看书,这样才能跟上时代的潮流,我强烈推荐你看POJOs In Action。不过这书挺贵,但别心疼钱。值。我也可以先给你唠叨唠叨。vo,一般也成为DTO,翻译过来就是数据传输对象,为啥当初要使用VO,因为最开始EJB时代,在处理分布式情况的时候,实体bean本身很重,使用VO是无奈之举,并不是说VO本身很nb,现在的Java理论已经摒弃了Vo的观念,因为现在已经是POJO的时代了,没想到现在一些PHPer竟然把Java的糟粕拿来做论据。。
昵称: thinkinginlamp  时间: 2007-08-16 21:28:00
引用:
原帖由 Haohappy 于 2007-8-16 20:59 发表
搞笑。。。我是说你的看法过时了。   你不是说Zend_Db不支持数据表间的关联吗?  这不是瞎扯吗?
嗯嗯。。。。。。。老王代我回答了一部分。

我再说说 Zend_Db_Table 的关联查询吧。

Zend_Db_Table 的关联查询只能从一条记录查该记录关联的记录:换句话说,如果我要查10个商品及其品牌信息,要么手写 SQL(就像 xgwork 那样),要么调用10次 findDependentRowset()、findParentRow()、findManyToManyRowset() 之类的方法。
这是多么的低效。。。。。。

工作先工作先,休息时间再来哈 :$
昵称: fleaphp  时间: 2007-08-16 21:44:00
真是没意思,没听说过连PHP的创始人都不支持使用Smarty啊?
人家说了,PHP本身就是模板语言。
靠,扯远了,这是讨论框架呵。不过我是菜鸟,看着大家高兴,也来凑个热闹。
到底谁实现好啊?
唉,咋理解呢?
如果适应某个需求,并且确实能提高应用,那就是好了。
但如果你实现的NX,但是没有实践需求,或者说需求不需要你这样做,那就是多于。
PS:此贴纯属灌水,基本可以飘过。。。

附带点儿技术的:
现在我有四张表:member,site,keyword,advertisement
关联关系如下:
memeber <mer_id> advertisement
site < sie_id > keyword
advertisement < adt_id > keyword
其中,左表对右表全部是one to many
现在我想:
1、一次查询获知哪个用户拥有哪个站点下的哪些广告及其所对应的关键字列表
2、一次添加一个广告,同时对应的站点、用户、关键字等相关信息都要更新
好了,就这两条吧,请你们给出各自的实现,对比一下吧。
多谢!

[ 本帖最后由 mcspring 于 2007-8-16 22:06 编辑 ]
昵称: mcspring  时间: 2007-08-16 21:55:00
引用:
原帖由 thinkinginlamp 于 2007-8-16 21:28 发表
首先,我觉得haohappy的心态已经失衡了,是你在贴子题目中写的请我和老廖进来的。可以我发现老廖回帖之后,你竟冷冷的说老廖的话搞笑,胡扯。。。
怎么不能说啊,自己说错的不承认,还故意曲解我的话,我说他看法过时,他还故意说成是我的看法过时。数据表关联的关系,还用他给我解释吗。你是正经讨论技术我就奉陪,废话一堆谁有空理你。

对你对Select的看法,我再请你以正常的话,不要说什么上下文情境,请问到底丑陋在哪,阁下有什么更好的解决方案?
昵称: Haohappy  时间: 2007-08-16 22:03:00
引用:
原帖由 thinkinginlamp 于 2007-8-16 21:28 发表
你帖子里说可以用joinLeft,对于你的解释,我只能说我们思维方式有差异,我说的是单单的Zend_Db_Table,如果你这样回答,那Zend_Db_Table已经无所不能了,大不了我用Db_Select构造一个SQL就好了,但记住,我说的是Db_Table。
事实很简单,只要稍微改装一下Db_Table,不管是哪种Join都可以轻易实现。而即使是RoR也是在1.1版本的时候才引进has_many :through,不知道你们急什么。 你有看到我用Select直接构造SQL吗?
昵称: Haohappy  时间: 2007-08-16 22:09:00
为什么我们需要 Zend_Db_Select
http://blog.xxiyy.com/index.php/archives/44

对于 select 我的看法比较简单~~因为实用,所以用~~~对于 Db Table 由于我严重不习惯这种使用数据表的方式,没有用~~~不过,我感觉,这不是我所期望的简单的数据操纵方式~~~
昵称: mikespook  时间: 2007-08-16 22:10:00
你们一见到就吵吵,吵吵啥呢。。。
昵称: rogman  时间: 2007-08-16 22:10:00
加入我说“XoX”你能明白我的意思啊?
还是回到技术吧,说说各自的实现怎么优秀就可以了,其他的都是扯蛋。

题外话:我是一个PHP新手,对于新手而言学习是必须的了。
请问,谁能让我在最短时间能学会某个框架?
我想这个应用中的成本中也是不小的比例吧?
我不能为了开发一套web应用系统,而去学习一门新的语言吧?
昵称: mcspring  时间: 2007-08-16 22:12:00
我觉得这个问题越争论越是没有意义了,不管是怎么实现,满足需求就好,虽然我没有深究过ZF,所以也没有什么发言权。但是,我还是说下我的感受,怎么来说,我也算用过和写过框架。其实无论是ZF还好,cakephp还好,始终都有自己的一套,你有你的实现,我有我的方式,就好比ThinkPHP和FleaPHP也是不同的实现一样。ZF是年轻了点,以后要走的路还很长,或许是ZF不想照搬现成的模式,想与众不同?有时候觉得ZF的约束比较少,但是同时提高了开发的复杂度,看起来ZF是站在一个框架的角度来开发这个框架的(这话说的有点拗口,其实我想表达的是ZF某些地方有些缺乏从使用者的角度去考虑),话又说回来,实现方式的不同而已,至于代码的多少也不能代表效率的高低。关于Vo的和数组的问题,其实,我也做过测试,在一般情况下面的差异是非常小的。并没有想象中的PHP数组效率多高那么严重,对象仍然是有他一定的优势,不难想象,ZF团队里面有这样的人存在,比较偏爱面向对象。而我呢,最终选择了让用户自己来选择使用对象还是数组,哈哈~
PS:我觉得我看了POJOs In Action后收获不大,呵呵~可能水平有限

[ 本帖最后由 liu21st 于 2007-8-16 22:39 编辑 ]
昵称: liu21st  时间: 2007-08-16 22:32:00
有感而发,怕引起争论,发布在我的博客上了~
http://www.topthink.com.cn/index.php/Blog
还是希望技术版块多点该有的东西,或者换个理性的方式~
昵称: liu21st  时间: 2007-08-16 23:18:00
引用:
附带点儿技术的:
现在我有四张表:member,site,keyword,advertisement
关联关系如下:
memeber <mer_id> advertisement
site < sie_id > keyword
advertisement < ked_id> keyword
其中,左表对右表全部是one to many
现在我想:
1、一次查询获知哪个用户拥有哪个站点下的哪些广告及其所对应的关键字列表
2、一次添加一个广告,同时对应的站点、用户、关键字等相关信息都要更新
好了,就这两条吧,请你们给出各自的实现,对比一下吧。
多谢!
还请老王用cakePHP、老廖用QeePHP、老刘用ThinkPHP及老陈用ZendFramework给出各自的实现代码,多谢合作!
然后我再给出需求的变化,你们再次各自修改实现,这样我想比较能容易看出来到底在开发过程中谁的实用性强了。。。

[ 本帖最后由 mcspring 于 2007-8-17 08:56 编辑 ]
昵称: mcspring  时间: 2007-08-17 08:51:00
http://jeremy.zawodny.com/blog/archives/002194.html
昵称: diogin  时间: 2007-08-17 12:23:00
引用:
原帖由 Haohappy 于 2007-8-16 22:09 发表
事实很简单,只要稍微改装一下Db_Table,不管是哪种Join都可以轻易实现。而即使是RoR也是在1.1版本的时候才引进has_many :through,不知道你们急什么。 你有看到我用Select直接构造SQL吗?
事实就是 ZF 的支持者根本听不得负面意见,总认为 ZF 才是最好的。
任何东西都有不足,如果听不得负面意见,还会有发展?
昵称: fleaphp  时间: 2007-08-17 14:15:00
引用:
原帖由 diogin 于 2007-8-17 12:23 发表
http://jeremy.zawodny.com/blog/archives/002194.html
数据库抽象层只不过是封装各个数据库之间的差异,以便为更上层的代码提供一个一致的访问数据库的接口。
现在大家争论的其实是说 ZF 的 DB 部分,并不是传说中那样完美,仍然有许多不足。可惜 ZF 的支持者们不愿意承认。
昵称: fleaphp  时间: 2007-08-17 14:16:00
引用:
原帖由 mcspring 于 2007-8-16 21:55 发表
附带点儿技术的:
现在我有四张表:member,site,keyword,advertisement
关联关系如下:
memeber <mer_id> advertisement
site < sie_id > keyword
advertisement < adt_id > keyword
其中,左表对右表全部是one to many
现在我想:
1、一次查询获知哪个用户拥有哪个站点下的哪些广告及其所对应的关键字列表
2、一次添加一个广告,同时对应的站点、用户、关键字等相关信息都要更新
好了,就这两条吧,请你们给出各自的实现,对比一下吧。
多谢!
good idea!
昵称: fleaphp  时间: 2007-08-17 14:18:00
引用:
原帖由 mcspring 于 2007-8-17 08:51 发表


还请老王用cakePHP、老廖用QeePHP、老刘用ThinkPHP及老陈用ZendFramework给出各自的实现代码,多谢合作!
然后我再给出需求的变化,你们再次各自修改实现,这样我想比较能容易看出来到底在开发过程中谁的实 ...
这个才是真正的good idea!
昵称: jasonqi  时间: 2007-08-17 14:44:00
引用:
原帖由 fleaphp 于 2007-8-17 14:15 发表


事实就是 ZF 的支持者根本听不得负面意见,总认为 ZF 才是最好的。
任何东西都有不足,如果听不得负面意见,还会有发展?
这里没有人认为ZF是完美的,大家都认为尚需完善。但提意见的人也要注意从技术角度来提,不要只凭臆断,信口开河。明明ZF有的功能,非要说成没有,这种勇气我真没有。错了还不承认。

我的态度是非常欢迎技术上的讨论,可是很显然你们都是在灌水而已。
昵称: Haohappy  时间: 2007-08-17 21:23:00
明明我们指出了 ZF 不存在或者不足的功能,你非不承认。。。。

就像关联操作,你倒是写两段代码来实践一下
昵称: fleaphp  时间: 2007-08-17 22:15:00
引用:
原帖由 fleaphp 于 2007-8-17 14:16 发表


数据库抽象层只不过是封装各个数据库之间的差异,以便为更上层的代码提供一个一致的访问数据库的接口。
现在大家争论的其实是说 ZF 的 DB 部分,并不是传说中那样完美,仍然有许多不足。可惜 ZF 的支持者们 ...
居然又是  一竿子打死一船人的 做法

佩服了

;P ;P ;P ;P ;P ;P
昵称: wangchun  时间: 2007-08-19 10:30:00
zend framework感觉有点鸡肋,太重。
昵称: danssion  时间: 2007-08-20 14:36:00
好啊,很久没有看到这样的讨论了,学习啊
昵称: hobbs136  时间: 2007-08-21 13:04:00
说实话 我虽然水平差但是我每次看到这种争论的问题的时候 fleaphp发炎总是挑衅 你就不能好好讨论问题啊 好歹你也是fleaphp的掌门人 拿出一点风度行不行
昵称: soitif  时间: 2007-08-22 08:33:00
引用:
原帖由 wanghaozi 于 2007-8-22 18:02 发表
说实话 我虽然水平差但是我每次看到这种争论的问题的时候 fleaphp发炎总是挑衅 你就不能好好讨论问题啊 好歹你也是fleaphp的掌门人 拿出一点风度行不行
搞不懂你们的思维,我怎么就挑衅了?
昵称: wanghaozi  时间: 2007-08-22 18:02:00
Haohappy  (陈浩),我支持你啊,
对ZF,我从0.15就开始在学习和使用,ZF功能的不断完善,不断加强,真的不错,才使得我们几个月公司从无到有已经做了好几个大的项目(人员配置更是差,jsp的,asp的都是新手,但现在都是在做PHP),对于一个团队来说,至少对于我来说,我也用了ZF,感觉就是,真的适合团队开发,这只是我个人意见.
Haohappy在对ZF中文化方面做了很多工作,是值得我们做程序员学习的,
像这样的讨论,我真怕是误了新人啊,一看到这里,一大片一大片的都是说ZF如何如何的错,一大片一大片的说FleaPHP如何如何比ZF功能好,真是没有意思,还是那句话,如果想要做产品就得老老实实的做,一直做到别人真正的说好,那才是好产品,
还有就是,不要有太多带有"攻击性"的语言,这样容易伤了感情,
还有就是,我也姓廖
昵称: fleaphp  时间: 2007-08-22 21:48:00
我想廖只是想说一些他认为zf存在的缺点,只是碍于他的身份才让大家有反感的情绪。。。

我本人也不是很欣赏zf,当然,没有十全十美的东西,我目前常用cakephp,它也有很多缺点,但是我觉得至少在理念上,cakephp这样的框架比zf更先进一些,当然,我知道zf fans们不会被我几句话说动,不过你们又试着真正去了解其他的框架么?CakePHP?Symfony?。。。

可能你们也会反问我真的了解zf么?!在zf还没出来的时候我就开始关注了,一直到现在,我时常还会看看,不过就像diogin说的:一个单层的包结构很无趣。。。我很赞同他的观点,这也是我为啥以前说目前的zf无非就是一个表现层框架而已。

我推荐大家几本书:

领域驱动设计,PoEAA,POJOs In Action,好好看看,有帮助。
昵称: liaoxw  时间: 2007-08-22 22:30:00
引用:
原帖由 liaoxw 于 2007-8-22 22:30 发表
Haohappy  (陈浩),我支持你啊,
对ZF,我从0.15就开始在学习和使用,ZF功能的不断完善,不断加强,真的不错,才使得我们几个月公司从无到有已经做了好几个大的项目(人员配置更是差,jsp的,asp的都是新手,但现在都是在做PHP),对于一个团队来说,至少对于我来说,我也用了ZF,感觉就是,真的适合团队开发,这只是我个人意见.
Haohappy在对ZF中文化方面做了很多工作,是值得我们做程序员学习的,
像这样的讨论,我真怕是误了新人啊,一看到这里,一大片一大片的都是说ZF如何如何的错,一大片一大片的说FleaPHP如何如何比ZF功能好,真是没有意思,还是那句话,如果想要做产品就得老老实实的做,一直做到别人真正的说好,那才是好产品,
还有就是,不要有太多带有"攻击性"的语言,这样容易伤了感情,
还有就是,我也姓廖
搞笑啊。。。。。。。你姓什么和我有啥关系?你如果觉得我让姓廖的蒙羞,那你改名好了。
昵称: thinkinginlamp  时间: 2007-08-22 22:51:00
只能说,可悲可悲啊,
昵称: fleaphp  时间: 2007-08-23 00:25:00
貌似小路老师也姓廖~~~:lol
------------------以上纯净水-----------------------
关于单层包结构之前已经讨论过,不过我觉得有必要继续讨论一下:

1. 什么是单层包结构,什么是多层包结构。
2. php 中如何实现多层包结构。
3. 哪些框架实现了多层包结构,这样做有什么好处。
4. 什么样的框架不是表现层框架,应该具有什么样的内容。

这四个问题如果能很好的解释的话,我想大家也不用在这里聒噪什么好,什么不好了~~
到底哪个框架在什么功能上或者用途上更有优势,解释清楚这四个问题,大家争论的关键点会清晰一些。

我再强调一下,我认为没有完美的框架,也没有最好的框架,只有最适合的框架~~~我是项目实用主义~~:lol ――实用就好!
昵称: liaoxw  时间: 2007-08-23 09:15:00
to mikespook,

1. 单层包结构(Controller,View,Db等等一大堆文件夹)就是所有的包都在一个大包下(Zend文件夹)。多层包结构就是把大包(比如Zend文件夹)分成逻辑上应该组织在一起的中级粒度包(比如Presentation,Application,Domain,Persistence,Toolkit等等),中层粒度包下面又有更小粒度的包(比如Application包可能包含Controller包,Presentation包可能包含View包,等等);
2. 见1;
3. 目前在PHP上很少见到,这也是我只是看看现有的大多数PHP框架的设计而不去使用它们的原因。多层包结构的好处是更加强调了包的职责分离功能,同时由于递归,使这种清晰的分离功能能在各种粒度上维持,增加系统的多种非功能特性;
4. 建议你参考一些框架设计和业务系统设计方面的书籍。

在PHP开发方面,PHP5还有非常多的开发模式因为开发人员拘泥于传统的开发方式而没有被很好地发掘出来。
最后一句话,“没有做不到的,只有你想不到,或者没去想,或不敢想而已”。
昵称: mikespook  时间: 2007-08-23 09:35:00
php的核心开发人员中有一些人对package的作用认识还不够(当然我非常佩服他们的C语言、操作系统和编译原理三方面的功力),导致前一段时间一直在争论namespace和package该用哪个。其实从large scale application来说,毫无疑问应该选package。但就这么一个简单的问题,他们却一直吵啊吵争啊争。。

看来,php社区始终是“争吵”的乐园。
昵称: diogin  时间: 2007-08-23 13:34:00
引用:
原帖由 liaoxw 于 2007-8-23 09:15 发表
只能说,可悲可悲啊,
太平日子过久了,许多人都没有血性了。

就像军事社区讨论造不造航母一样,许多人的思维就是:美国的技术是最领先的,中国不可能超过。
要是当年搞两弹一星的人也这样想,那现在的中国要预报一下暴雨,还得买别人的卫星云图(前提是别人没有封锁你,愿意赚你的钱)。

当然,PHP 开发框架和两弹一星不是一个层次的东西。
但是我们今天做 FleaPHP、QeePHP,就是为了走出自己的路。虽然不一定能够全面超越国外的框架,可如果做都不去做,就永远只有跟在别人后面走。

日本也有不少 PHP 开发框架,虽然在国际上不知名,但是在国内有许多用户。
而且他们也不谦虚,号称是全世界最先进的 PHP 开发框架。
我想日本的开发者相信自己有这个实力,所以敢于这样喊出来。
而且他们一样撰文阐述自己的框架为什么就比国外的好,可没见人去骂他们,说他们素质低下、人品不好。

所以还是心态平和点,不要只知道用,还要学会思考。
至于可悲不可悲,不是你操心的问题。要是整天杞人忧天,不如改行写言情小说。
昵称: diogin  时间: 2007-08-23 13:44:00
引用:
原帖由 diogin 于 2007-8-23 13:34 发表
to mikespook,

1.单层包结构(Controller,View,Db等等一大堆文件夹)就是所有的包都在一个大包下(Zend文件夹)。多层包结构就是把大包(比如Zend文件夹)分成逻辑上应该组织在一起的中级粒度包(比如Presentation,Application,Domain,Persistence,Toolkit等等),中层粒度包下面又有更小粒度的包(比如Application包可能包含Controller包,Presentation包可能包含View包,等等);
2. 见1;
3. 目前在PHP上很少见到,这也是我只是看看现有的大多数PHP框架的设计而不去使用它们的原因。多层包结构的好处是更加强调了包的职责分离功能,同时由于递归,使这种清晰的分离功能能在各种粒度上维持,增加系统的多种非功能特性;
4. 建议你参考一些框架设计和业务系统设计方面的书籍。

在PHP开发方面,PHP5还有非常多的开发模式因为开发人员拘泥于传统的开发方式而没有被很好地发掘出来。
最后一句话,“没有做不到的,只有你想不到,或者没去想,或不敢想而已”。
PHP 本身不支持 package 概念,即便逻辑上是多层的,但在语言表现上,仍然是平行的。
而像 ZEND_Db、FLEA_Db 这样的命名规范,都属于一种 namespace 的模仿。

至于 mikespook 提出的第四点,我很意外。
如果只是解决表现层问题,PHP 自身就能办到,根本不需要借助任何框架,因为 PHP 自身就是一种可以嵌入到表现层的脚本。
昵称: fleaphp  时间: 2007-08-23 22:13:00
引用:
原帖由 fleaphp 于 2007-8-23 22:13 发表


太平日子过久了,许多人都没有血性了。

就像军事社区讨论造不造航母一样,许多人的思维就是:美国的技术是最领先的,中国不可能超过。
要是当年搞两弹一星的人也这样想,那现在的中国要预报一下暴雨,还 ...
这样吵着真没有意思,不是许多人的思维是这样,事实是怎样就怎样,如果连这点判断能力都没有,那就不要做人了,说白了,还是人品有问题,要得别人尊重自己,先得尊重别人,框架都是这样,你熟了就觉得它好,
国内的发展,我还是想事实求事,如果只是说口头上打一下口号,实际上又不是那么一回事,那才是悲哀啊,
任何技术超过外人,都是好事,但绝不要拿来比,就算比,也不要用单方的意见,再好的东西没人用,也就不是好东西,再差的东西,用的人多了,自然也就成了好东西,
windows,mac os,linux ,国人大部分人为什么说 windows是好用的,其中最好的又是什么呢,这个道理大家都明白,

[ 本帖最后由 liaoxw 于 2007-8-24 09:31 编辑 ]
昵称: fleaphp  时间: 2007-08-23 22:25:00
引用:
这样吵着真没有意思,不是许多人的思维是这样,事实是怎样就怎样,如果连这点判断能力都没有,那就不要做人了,说白了,还是人品有问题,要得别人尊重自己,先得尊重别人,框架都是这样,你熟了就觉得它好,
国内的发展,我还是想事实求事,如果只是说口头上打一下口号,实际上又不是那么一回事,那才是悲哀啊,
任何技术超过外人,都是好事,但绝不要拿来比,就算比,也不要用单方的意见,再好的东西没人用,也就不是好东西,再差的东西,用的人多了,自然也就成了好东西,
windows,mac os,linux ,国人大部分人为什么说 windows是好用的,其中最好的又是什么呢,这个道理大家都明白,
事实?就你看到事实了?自以为看到了真相 -_-#

[ 本帖最后由 fleaphp 于 2007-8-24 11:43 编辑 ]
昵称: liaoxw  时间: 2007-08-24 09:17:00
开始几贴都还好
后来越来越不像话了
扯到哪去了
什么乱七八糟
有些甚至是版主
明显违反版规!

[ 本帖最后由 ifblue 于 2007-8-25 15:53 编辑 ]
昵称: fleaphp  时间: 2007-08-24 11:42:00
希望大家能够安静理智的回到问题上来,若问题解决,就封贴。

[ 本帖最后由 ifblue 于 2007-8-25 15:54 编辑 ]
昵称: ifblue  时间: 2007-08-25 15:45:00
知道什么叫疯狗吗?疯狗就是逮谁就咬谁~
昵称: ifblue  时间: 2007-08-25 15:51:00
引用:
原帖由 fleaphp 于 2007-8-23 22:13 发表


但是我们今天做 FleaPHP、QeePHP,就是为了走出自己的路。虽然不一定能够全面超越国外的框架,可如果做都不去做,就永远只有跟在别人后面走。
大家不要吵了,现在大家用的php都是美国产品,如果你想走出自己的路的话,就开发一种语言吧,我绝对支持。好像日本的Ruby一样。不要用外国的语言..............
昵称: aultoale  时间: 2007-08-26 14:24:00
引用:
原帖由 liexusong 于 2007-9-8 13:30 发表


大家不要吵了,现在大家用的php都是美国产品,如果你想走出自己的路的话,就开发一种语言吧,我绝对支持。好像日本的Ruby一样。不要用外国的语言..............
美国产品?如果是指 zend 公司的产品的话,我认可 PHP 是这个公司的产品。同时,我不认为 php 属于哪个国家,php 属于所有正在使用,并对其有贡献的人。

另外,貌似 Zend US 都是不存在的,美国的 zend 的生意是加拿大总部直接管辖的。呵呵~~
昵称: liexusong  时间: 2007-09-08 13:30:00
要为国争光要拿出为国争光的肚量来,在这里你正在把可能成为你框架的用户扼杀在摇篮里
昵称: mikespook  时间: 2007-09-08 15:46:00
;P 我是从zf转到fleaphp上的 感觉上没有用过zf或fleaphp的人在这里没发言权。。。都不去用怎么知道哪个好哪个不好呢?;P 不过目前我是混着来用的哈~ 各有千秋
昵称: chenz1117  时间: 2007-09-13 13:36:00
呵呵,这期给 PHPer 写了一篇文章,标题是《在 FleaPHP 应用程序中使用 Zend Framework 组件》。
到时候请楼上多多提意见 :handshake
昵称: edwardhey  时间: 2007-09-26 22:25:00
原来这里这么热闹呀.看来以后多来这里看看了.
本人也支持国产,不过现在还没用过.
哈哈.[url=space-uid-4020.html]个人很欣赏 "liu21st"[/url]
说话比较客关.有水平.有机会交个朋友吧.
昵称: fleaphp  时间: 2007-09-26 22:39:00
引用:
原帖由 fleaphp 于 2007-9-26 22:39 发表
呵呵,这期给 PHPer 写了一篇文章,标题是《在 FleaPHP 应用程序中使用 Zend Framework 组件》。
到时候请楼上多多提意见 :handshake
给意见倒是不行了哈~ 是向你学习拉~
昵称: wm2008  时间: 2007-09-28 09:43:00
:D :D :D :D :D :D
昵称: edwardhey  时间: 2007-09-28 18:42:00