12

ORMを使用している場合、リポジトリパターンはどのようなメリットがありますか？

例。次の（架空の）テーブルがあるとします。

表：ユーザー

pk_user_id
fk_userrole_id
username

表：ユーザーロール

fk_userrole_id
role

これで、ormを使用して、これをモデルファイルに入れることができます。

$user = ORM::load('users', $id);

これで、$ userはすでに私のオブジェクトであり、簡単に遅延ロードできます。

（物事が自動的に単数形/複数形になるとさらに良いでしょう）

foreach ( $user->userroles()->role as $role )
{
    echo $role;
}

リポジトリパターンを使用して、ユーザー用のリポジトリとロール用のリポジトリを作成する必要がありました。リポジトリには、データを取得して保存するためのあらゆる種類の関数も必要です。さらに、エンティティモデルで動作する必要があります。だから私もそれらすべてを作成する必要があります。

私には、多くのことが行われているように見えます...ORMを使用して上記のようなデータを簡単に取得できたとき。そして、私はそれを同じように簡単に保存することができました：

ORM :: store（$ user）;

この場合、ユーザーオブジェクトをデータベースに保存するだけでなく、「ロール」オブジェクトに加えた変更も保存します。したがって、リポジトリパターンで必要なような余分な作業は必要ありません...

だから私の質問は基本的に、なぜ私はORMでリポジトリパターンを使用したいのですか？そのパターンを使用するチュートリアルを見てきました（Doctrineのように）。しかし、それは本当に私には意味がありません...ORMと組み合わせて使用​​するための説明はありませんか？

4

2 に答える 2

21

ORMは、リポジトリの実装の詳細です。ORMを使用すると、OOPに適した方法でdbテーブルに簡単にアクセスできます。それでおしまい。

リポジトリは、ストレージが何であれ、永続性アクセスを抽象化します。それがその目的です。dbまたはxmlファイルまたはORMを使用しているという事実は重要ではありません。リポジトリにより、アプリケーションの残りの部分は永続性の詳細を無視できます。このようにして、モックまたはスタブを介してアプリを簡単にテストでき、必要に応じてストレージを変更できます。今日はMySqlを使用するかもしれませんが、明日はNoSqlまたはCloudStorageを使用することをお勧めします。ORMでそれを実行してください！

リポジトリは（アプリの観点から）ドメイン/ビジネスオブジェクトを処理し、ORMはdbオブジェクトを処理します。ビジネスオブジェクトはdbオブジェクトではなく、最初は動作があり、2番目は栄光のDTOであり、データのみを保持します。

編集 リポジトリとORMの両方がデータへのアクセスを抽象化すると言うかもしれませんが、悪魔は詳細にあります。リポジトリはすべてのストレージの懸念事項へのアクセスを抽象化し、ORMは特定のRDBMSへのアクセスを抽象化します

一言で言えば、リポジトリとORMには異なる目的があり、上で述べたように、ORMは常にリポジトリの実装の詳細です。

リポジトリパターンの詳細については、この投稿を確認することもできます。

于 2012-04-15T08:48:34.863 に答える
4

ORMとリポジトリパターン...はセットアップによって異なります。

  1. ORMエンティティをドメインレイヤーとして使用する場合は、リポジトリを使用しないでください。
  2. 別のドメインモデルがあり、そのモデルからORMエンティティにマップして保存を実行する必要がある場合は、リポジトリが必要です。

詳細については、こちらをご覧ください（ただし、LinkedInにログインする必要があります）。また、違いを理解するには、リポジトリパターンの定義を確認してください。

ほとんどの人は、リポジトリと呼ばれるクラスを使用しますが、リポジトリではなく、クエリクラスだけです。これは、 ＃1オプションを選択した場合にクエリを配置する方法/場所です（上記の回答を参照）。この場合、そのクエリクラスからDbContextまたはISessionを公開したり、そこからCUDメソッドを公開したりしないようにしてください。Queryクラスを覚えておいてください。

＃2のオプションは難しいものです。実際のリポジトリを実行する場合、リポジトリインターフェイスのすべての入力と出力には、明確なドメインクラスが含まれます（データベース関連のオブジェクトは含まれません）。そこからORMマップクラスまたはORMアーキテクチャ関連オブジェクトを公開することは禁止されています。Saveメソッドもあります。これらのリポジトリにはクエリも含まれる場合がありますが、クエリクラスとは異なり、これらのリポジトリはより多くのことを行います。ドメイン集約（エンティティのコレクションとツリー）を取得し、それらのクラスをORMクラスにマッピングして、ORMで保存を実行することにより、DBに保存します。このスタイル（＃2）はORMを使用する必要はなく、リポジトリパターンは主にADO.NET（あらゆる種類のデータアクセス）用に作成されました。

とにかく、これらの2つのオプションは、私たちが実行できる2つの極端な方法です。多くの人がORMでリポジトリを使用しますが、実際の関数を使用せずにコードのレイヤーを追加するだけです。実際の関数は、動作のようなクエリクラスだけです。

また、誰かがUnitOfWorkについて、特にORMと話すときは、注意が必要です。インターネット上のほとんどすべてのサンプルは、アーキテクチャの観点からは失敗です。UoWが必要な場合は、TransactionScopeを使用しないでください（デフォルトでSerializableトランザクション以外を使用するラッパーを取得していることを確認してください）。99,9％では、データの2セットの独立した変更（つまり2セットのOuW）を管理する必要がないため、TransactionScopeは.NETの優れた選択肢になります-PHPの場合はオープンセッションを探します-実装を表示...

于 2017-02-26T15:24:03.103 に答える