Zend Framework ORM风格的表数据网关与扩展Zend_Db_Table_Abstract

Question

在Zend Framework快速入门中,从扩展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();
}

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

毫无疑问,我忽视了一些事情,所以我很乐意听取你的意见.

问题:

• 有人可以向我解释为什么(或者如果)后者是更好的做法？

• 我应该从旧的方式切换到新的方式还是仍然有适当的理由坚持代表数据库表的模型？

提前致谢.

Answer 1

以下是我为什么这是一个更好的做法的解释:

我认为真正的好处是能够无缝地更改您的数据源.通过在应用程序中添加一个额外的抽象层,您的模型不再代表数据库表(在我看来它永远不应该),因为模型应该是数据的表示(不是它的网关).数据库访问层应该由模型封装,从而为您提供更大的灵活性.

例如,假设您的应用程序需要开始使用SOAP服务或XML-RPC作为其数据源/存储.通过使用数据映射器方法,您具有明显的优势,因为您已经拥有必要的结构来添加这些特定的数据层接口,而不会对现有模型造成太大(如果有)干扰.

你应该这样做吗？这是一个务实的问题.就个人而言,我喜欢安心,我正在开发一些灵活的东西并遵循(同意)最佳实践.但是,只有您知道创建更灵活的应用程序是否会使您的项目在现在或将来的某个时间更容易构建和维护.

对我来说,我只是喜欢我正在构建一些东西的感觉,我认为这是最佳实践,它通常会带来好处.