Zendでは、なぜDBモデルクラスとマッパークラスを2つの別々に使用するのですか？

Question

私はZend Projectに取り組んでいます。他のZendプロジェクトを参照してNew Zend Projectを作成していますが、理解せずに盲目的にそのプロジェクトをフォローしたくありません。 Zend Directory構造には、モデルクラスには、主に私が見る2つのタイプのクラスがあります。

- models
   - DbTables
        - Blog.php  //Extends Zend_Db_Table_Abstract
   - Blog.php       // Contains methods like validate() and save()
   - BlogMapper.php // Also Contains methods like validate(Blog b) & save(Blog b)

なぜこの特定の構造に従うのですか？これは、オブジェクトクラスとデータベースモデルのクラスを分離することですか？

説明してください。

Answer 1

Datamapperは、エンタープライズアプリケーションアーキテクチャのパターンからの設計パターンです.

データマッパーは、インメモリオブジェクトをデータベースから分離するソフトウェアのレイヤーです。その責任は、2つの間にデータを転送し、それらを互いに隔離することです。データマッパーを使用すると、メモリ内のオブジェクトはデータベースが存在することを知る必要はありません。 SQLインターフェイスコードは必要ありませんし、データベーススキーマの知識は確かにありません。

データをリレーショナルデータベースに保存する方法は、通常、メモリ内のオブジェクトを構成する方法とは異なります。たとえば、オブジェクトには他のオブジェクトが付いた配列がありますが、データベースには、代わりにテーブルに別のテーブルの外部キーがあります。のためです オブジェクトリレーショナルインピーダンスの不一致, 、ドメインオブジェクトとデータベースの間に媒介レイヤーを使用します。このようにして、他のものに影響を与えることなく両方を進化させることができます。

独自のレイヤーでマッピング責任を分離することは、 単一の責任の原則. 。あなたのオブジェクトは、DBロジックについて知る必要はありません。その逆も同様です。これにより、コードを書くときに柔軟性が高まります。

ドメインモデルを使用したくない場合、通常、データマッパーは必要ありません。データベーステーブルがシンプルである場合は、テンブルドールとTabledatagateway、またはActivereCordだけでよい場合があります。

他のさまざまなパターンについては、私の答えをご覧ください

• ORM/DAO/DATAMAPPER/ACTIVERECORD/TABLEGATEWAYの違い？ と
• http://martinfowler.com/eaacatalog/index.html

Answer 2

モデルのアイデアは、コード内にデータの論理コレクションをまとめることです。

データマッパーのアイデアは、このアプリケーションレベルのデータコレクションを、あなたがそれを保存する方法と関連付けることです。

多くのActiverCordの実装では、このフレームワークはこの意図の分離を提供せず、これが問題につながる可能性があります。たとえば、ブログポストモデルは、次のようなブログ投稿の基本情報をまとめることができます

• 題名
• 著者
• 体
• date_posted

しかし、多分あなたはそれにそれを含むことも望んでいます：

• number_of_reads
• number_of_likes

これで、このすべてのデータを1つのMySQLテーブルに保存することができますが、ブログが成長し、非常に有名になると、統計データが非常に多くのヒットを取っていて、別のデータベースサーバー。

アプリケーションコードを変更せずに、ブログポストオブジェクトのフィールドを別のデータストアに移行するにはどうすればよいですか？

DataMapperを使用すると、オブジェクトの保存方法とデータベースからロードされる方法を変更できます。これにより、アプリケーションが依存している情報の実際の収集を変更することなく、ストレージメカニズムを調整できます。