3

私は現在、PHP で Doctrine ORM を使用して Active Record パターンに依存するサイトを持っています。私は通常、このアプローチのファンです。これは非常に簡単で、単純な CRUD アプリの管理に適しています。しかし、このサイトが成長するにつれて、より堅牢なドメイン機能の必要性も高まると思います. ORM と組み合わせてうまく機能する他の種類のデータ設計パターンを知りたいと思っていました。

現在の私の基本的な問題は、Doctrine が派手なクエリ言語として最適に機能するように思われるため、私のモデルには次のようなメソッドが散らばっていることです。

function getBySomeClassfication($classification)
{
    return Doctrine_Query::create()
              ->select('stuff')
              ->from('ModelClass')
              ->where('something = ?', $classification)
              ->execute();
}

またはモデルクラスに直接アクセスしたい場合：

Doctrine::getTable('ModelClass')->findAll();

つまり、ドメイン オブジェクトを直接操作するのではなく、Doctrine のオブジェクト ラッパーを使用することになります。これはすべて、より低いレベルの抽象化に存在する必要があるように感じます。

最善のアプローチが何であるかはよくわかりません。ORM は、単一のテーブルにクエリを実行し、リレーションシップを処理するための優れたレイヤーだと思います。しかし、複数のモデル/テーブルで機能するドメイン オブジェクトを作成する際の柔軟性を高めたいと考えています。

リポジトリ パターンの使用について調べましたが、まだいくつかためらいがあります。

  1. 元の問題を単純に泡立てる無意味な抽象化のレイヤーを作成したくありません。

  2. Active Record ORM を使用することの要点全体を再作成したり、役に立たなくしたりしたくありません。

何か考えや提案はありますか？

4

2 に答える 2

1

ある時点でオブジェクト ラッパー (データ アクセス オブジェクト) を操作する必要があり、ある時点で呼び出しが実装 (ここでは Doctrine-) 固有になります。それは主に、間にいくつのレイヤーを配置するかについて、現在のアーキテクチャに依存しますが、可能な限り少なくします。Doctrine で解決できない特定の問題はありますか?

ORM を (最初から) オブジェクト指向ドメイン モデルを開発するためのツールとして使用する場合、データベースの詳細 (複数のテーブルにまたがる 1 つのドメイン エンティティなど) を処理する意味がまったくわからないことがあります。私は最近、Java 固有の質問 hereに回答しましたが、アーキテクチャのアイデアにも役立つかもしれません。

于 2009-08-05T14:32:03.803 に答える
0

Zend Framework ORMの実装（まだ行っていない場合）をご覧になると、複数のテーブル間の関係を定義することもできます。

それがお役に立てば幸いです。

于 2009-08-05T14:23:15.033 に答える