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

Question

在Zend Framework Quickstart ，从扩展 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

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

我认为这样做的真正好处是能够无缝更改您的数据源。通过在您的应用程序中添加额外的抽象层，您的模型不再代表数据库表(在我看来它永远不应该代表)，因为模型应该代表数据(而不是数据的网关)。数据库访问层应该被模型封装起来，让你有更大的灵 active 。

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

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

对我来说，我只是喜欢我正在构建一些东西的感觉，我认为这是最佳实践并且它通常会带来红利。