Zend Framework ORM 样式表数据网关与扩展 Zend_Db_Table_Abstract

Posted 2023-02-24

【中文标题】Zend Framework ORM 样式表数据网关与扩展 Zend_Db_Table_Abstract

【英文标题】：Zend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract

【发布时间】：2010-11-07 00:18:14

【问题描述】：

在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();

由于我缺乏这种编程风格的经验，我发现很难掌握后一种方式的实际好处；我知道这种方法尽可能地将数据库与实际逻辑分开，这在理论上应该更容易过渡到另一个数据库平台。但是，我真的不认为我正在从事的任何项目都会发生这种情况。

毫无疑问，我忽略了一些东西，所以我很想听听你的建议。

问题：

有人可以向我解释一下为什么（或是否）后者是更好的做法吗？

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

提前致谢。

【问题讨论】：

不是真正的答案，所以是她。几年后我发现抽象是一种艺术形式，艺术并不总是有原因的。今天我抽象了我需要的最低限度并做一些事情，所以我必须尽可能少地编码，在你的情况下，如果添加这个额外的抽象级别，就不会发生。

澄清一下，Zend_Db_Table 是 TDG/RDG 模式的实现。正在发生的事情是他们正在转向 Data Mapper 模式。

【参考方案1】：

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

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

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

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

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

【讨论】：

虽然您确认了我的想法，但这对我的问题的两个部分来说都是一个很好的答案，并且肯定会帮助我做出更好的决定。谢谢！

很高兴我能帮上忙。此外，如果您想进一步阅读，Matthew Weier O'Phinney 提供了一些有用的幻灯片，这些幻灯片来自他在荷兰 php 会议上的演示文稿。 slideshare.net/weierophinney/zend-framework-workshop-dpc09（幻灯片 28 是模型讨论的起点）。

有趣我似乎也无法理解这个概念：P 这似乎有点像过度工程。如果数据源发生变化，更改映射器而不是更改模型有什么不同？在实践中，这种情况真的发生了多少次，要写一些额外的行来写一些只会让我的感觉更加臃肿的东西：p 但我知道什么

2011 年，我们到了。我的想法是：遵循 SCRUM 模型 (XP)，当您真正觉得有必要时添加数据映射器。更少的编码，更多的功能和重构。

【参考方案2】：

它很有用，因为你可以做$insert = new Model_Guestbook($param1, $param2, $param3); - 意味着当有人来到项目时，他可以在不了解数据库结构的情况下轻松创建一个新实例（通过检查源/模型接口）。这只是此方法提供的好处之一:)

【讨论】：

我并不认为这是一个很大的好处，因为这意味着架构更改会导致需要在多个地方更改相应的代码。我仍然觉得我严重忽视了一些东西。