0

Zend クイック スタート ガイドによると、テーブル データ ゲートウェイ パターンを実装するには、3 つのクラス (モデル、マッパー クラス、テーブル ゲートウェイ クラス) が必要です。しかし、これは良いアプローチですか？

今、これが私がパターンを実装する方法です。

class Application_Model_Person(){
    private $_name;

    public function getName();
    public function setName($name);
}   

class Application_Model_PersonMapper extends Zend_Db_Table_Abstract {

      public function fetch();
      public function search();
      public function save(Application_Model_Person $person);
      public function delete();

}

したがって、すべての getter/setter メソッドを含むモデル クラスと、Zend_Db_Table_Abstract クラスを拡張してすべての crud 操作を実行する別のクラスがあります。クラスの数が減り、従いやすいので、このアプローチが気に入っています。しかし、これは適切な方法ですか？

また、Zend クイック スタート ガイドのアプローチを使用すると、どのような利点がありますか?

4

1 に答える 1

2

実際にはプロジェクトのサイズによって異なります。ZF は、私が「エンタープライズ対応」と呼んでいるものです。つまり、大規模な Web アプリケーションを構築します。私の考えでは、これらのパターンに従って、ほぼ無限にスケーリングできます。ただし、多くの小規模なプロジェクトでは、これはやり過ぎになる可能性があります。

あなたの例で私が目にする唯一の問題は、マッパーを DbTable に拡張することです。これは、一般的なパターンに従っているだけです。小規模なプロジェクトの場合、モデル (外部 - アプリケーション ビュー) を持ち、DbTable クラス (内部 - Db ゲートウェイ) に直接アクセスして、マッパーをスキップすることができます。

後でなんらかの理由で特定のテーブルにマッパーが必要だと判断した場合は、かなり簡単に実装できるはずです。

于 2013-02-23T16:54:58.120 に答える