問題タブ [table-data-gateway]

デザインパターンのスキルを磨こうとしていますが、これらのパターンの違いは何ですか？それらはすべて同じもののように見えます。特定のエンティティのデータベースロジックをカプセル化して、呼び出し元のコードが基盤となる永続層を認識しないようにします。私の簡単な調査から、それらはすべて、通常、標準のCRUDメソッドを実装し、データベース固有の詳細を抽象化します。

命名規則（例：CustomerMapper、CustomerDAO、CustomerGateway、CustomerRepository）とは別に、違いは何ですか？違いがある場合、いつどちらを選びますか？

以前は、次のようなコードを記述していました（単純化すると、当然、通常はパブリックプロパティを使用しません）。

そしてCustomerGateway、すべてのメソッドに特定のデータベースロジックを実装するクラスがあります。インターフェースを使用せず、CustomerGatewayのすべてのメソッドを静的にすることがあるので（テストが難しくなることはわかっています）、次のように呼び出すことができます。

これは、データマッパーパターンとリポジトリパターンの場合と同じ原則のようです。DAOパターン（ゲートウェイと同じだと思いますか？）も、データベース固有のゲートウェイを促進しているようです。

私は何かが足りないのですか？同じことを3〜4つの異なる方法で行うのは少し奇妙に思えます。

zf2 の tableGateway を使用していますが、それがもたらす設計がわかりません。

zf2 の tableGateway を使用して挿入を行う方法の標準的な例を次に示します (これは docs からのものです)。

しかし、次のような Album クラスが既にあるため、 $data 配列を定義するのは冗長に思えます。

私自身のプロジェクトでは、約 25 のプロパティ (25 列のテーブル) を持つモデルがあります。25 個のプロパティを持つクラスを定義し、それらのプロパティごとに要素を持つ tableGateway を実装するクラスのメソッド内に $data 配列を記述する必要があるのは冗長に思えます。何か不足していますか？

以前、tablegateway を使用して挿入\更新を効率的に行う方法について質問したところ、ドキュメントの次のZend\Stdlib\Hydrator\ClassMethodsコードのように通知されました。

次のコードに置き換えることができます。

しかし、$hydrator->extract($album);それを使用すると空の配列が返されることがわかりました。これの原因は何でしょうか? 関数に渡されるオブジェクトで実行しましたが、有効なようvar_dump()です。$albumこれを機能させるために他に何かしなければならないことはありますか？

単純なデータベース抽象化レイヤーを作成しようとしています。Active Record と Table Data Gateway に関する記事をたくさん読みましたが、今は非常に混乱しています。

それらについてのいくつかの理論（小さな）は理解していると思いますが、それらを正確に実装する方法はわかりません。Data Table Gateway を実装することにしました。私がしたことを説明しようと思います。アドバイスをいただければ幸いです。モデルで DI のようなテーブル データ ゲートウェイを使用する必要があるたびに (たとえば、ZF2 で) 理由がわかりません。

私の場合、AbstractModel は IoC コンテナーによってコンストリクターで DbAdapter を取得するだけですが、これで問題ないかどうかはわかりません。わかりました、私の状況を説明します。私は次のクラスを持っています：

• DbAdapter -> db 接続を作成します (PDO を使用)
  
• IoC (制御コンテナーの反転)
  
• AbstractModel -> コンストラクターで IoC を使用して DbAdapter を取得します。これは、DbAdapter のインスタンスを 1 つだけ保持することを意味します。このクラスには CRUD メソッドもあります。
  
• 別のクラスは、db のテーブルを表します。たとえば、クラス User は AbstractModel を拡張し、テーブルの名前を返すメソッド getTable を持っています。別の SQL クエリは、テーブルを表すこのクラスにあります。これらのクラスは DbAdapter にアクセスできます。
  

このスキームは問題ありませんか?どうすれば改善できますか?