Zend Framework ORM 风格的表数据网关与扩展 Zend_Db_Table_Abstract [英] Zend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract

问题描述

在 Zend 框架快速入门中，从将 Zend_Db_Table_Abstract 扩展到表数据网关模式的模型发生了变化.

In the Zend Framework Quickstart, there has been a change from models that extend Zend_Db_Table_Abstract to the Table Data Gateway pattern.

就我个人而言，我对这种模式没有太多经验，我一直听说最有可能使用这种模式而不是旧方式.

Personally, I have not had much experience with this pattern and I keep hearing this should most likely be used instead of the old way.

快速入门中的一个简短示例:

老方法:

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

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

From my lacking experience with this style of programming, I find it hard to grasp the actual benefits from this latter way; I understand that this method seperates the database from the actual logic as much as possible, which should in theory make a transition to another database platform easier. However, I really don't see this happening on any project I am working.

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

There is almost no doubt that I am overlooking something, so I'd love to hear your advice.

问题:

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

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

提前致谢.

推荐答案

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

Here's my explanation at why this is a better practice:

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

I think the real benefit to this is the ability to seamlessly change your data sources. By adding an additional layer of abstraction into your application, your models no longer represent a database table (it never should have, in my opinion) as a model should be a representation of the data (not a gateway to it). The database access layer should be encapsulated by the model, allowing you more flexibility.

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

Say, for instance, your application needed to start using a SOAP service or XML-RPC as it's data source/storage. By using the data mapper approach, you are at a distinct advantage, as you already have the necessary structure in place to add these specific data layer interfaces without much (if any) interference with your existing models.

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

Should you do it, though? That's a pragmatic question. Personally, I like to have the peace of mind that I'm developing something that is flexible and follows (agreed on) best practices. However, only you know whether creating a more flexible application will make your projects easier, either now or some time in the future, to build and maintain.

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

For me, I just like the feeling that I'm building something, I consider to be best-practice and it often pays dividends.

这篇关于Zend Framework ORM 风格的表数据网关与扩展 Zend_Db_Table_Abstract的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！