2009-06-30 17 views
9

Zend Framework Quickstart中,从扩展Zend_Db_Table_Abstract的模型到表格数据网关模式有所变化。Zend Framework ORM样式的表数据网关与扩展Zend_Db_Table_Abstract

就我个人而言,我对这种模式没有太多的经验,我一直听到这个应该最有可能被用来代替旧的方式。

从快速入门的简单例子:

老办法:

class Default_Model_Guestbook extends Zend_Db_Table_Abstract 
{ 
    protected $_name = 'tablename'; 

    // do stuff 
} 

新方法:

// The actual model 
class Default_Model_Guestbook 
{ 
    protected $_comment; 
    protected $_created; 
    protected $_poster; 
    // list continues with all columns 
} 

// Dbtable for this model 
class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract 
{ 
    /** Table name */ 
    protected $_name = 'guestbook'; 
} 

// Mapper 
class Default_Model_GuestbookMapper 
{ 
    public function save($model); 
    public function find($id, $model); 
    public function fetchAll(); 
} 

从我用这种编程风格缺乏经验,我发现很难掌握实际情况l受益于后一种方式;我知道这种方法尽可能地将数据库从实际的逻辑中分离出来,这在理论上应该更容易地转换到另一个数据库平台。但是,我真的没有看到这发生在我工作的任何项目上。

几乎毫无疑问,我忽略了一些东西,所以我很乐意听取您的建议。

问题:

  • 可能有人请向我解释为什么(或者),后者是更好的做法?

  • 我应该从旧的方式切换到新的方式或仍然会有适当的理由与代表数据库表款坚持?

在此先感谢。

+0

不是一个真正的答案,所以这是她的。几年后,我发现抽象是一种艺术形式,艺术并不总是有原因的。今天,我抽象出我需要的最低限度,并且做一些事情,这样我就不得不尽可能少地编写代码,在你的情况下,如果增加这个额外的抽象层次,将不会发生。 – 2009-06-30 13:34:28

+0

为了澄清,Zend_Db_Table *是* TDG/RDG模式的实现。发生的是他们正在转向Data Mapper模式。 – jason 2009-06-30 15:31:49

回答

6

这里是我在为什么这是一个更好的做法的解释之一:

我觉得真正利益,这是无缝地改变你的数据源的能力。通过在您的应用程序中添加一个额外的抽象层,您的模型不再代表数据库表(我认为它绝不应该有),因为模型应该是数据的表示(而不是通往它的网关)。数据库访问层应该由模型封装,让您有更大的灵活性。例如,假设您的应用程序需要开始使用SOAP服务或XML-RPC,因为它的数据源/存储空间不足。通过使用数据映射器方法,您具有明显的优势,因为您已经具备必要的结构来添加这些特定的数据层接口,而不会对现有模型产生太多(如果有的话)干扰。

你应该这样做吗?这是一个实用的问题。就我个人而言,我喜欢让自己放心,我正在开发一些灵活并遵循(商定的)最佳实践的东西。但是,只有您知道创建更灵活的应用程序是否会使您的项目更容易,无论是现在还是未来的某个时间,都可以构建和维护。

对我来说,我只是觉得自己在创造一些东西,我认为这是最佳实践,而且通常会带来红利。

0

这很有用,因为你可以这样做$insert = new Model_Guestbook($param1, $param2, $param3); - 意味着当有人来到项目中时,他可以在不知道数据库结构(通过检查源/按模型接口)的情况下轻松创建新实例。这仅仅是这种方法提供的好处:)

+0

我并不认为这是一个很大的好处,因为这意味着模式更改会导致需要在多个地方更改相应的代码。我仍然觉得我彻底忽略了一些东西。 – 2009-07-01 07:43:40