質問

Laravelの優れたデザインパターンに関するT. Otwellの本を読んだ後、Laravel 4でアプリケーションを作成しているとき、アプリケーション上のすべてのテーブルのためにリポジトリを作成していることに気づきました。

結局、次のようなテーブル構造になりました。

• 学生：ID、名前
• コース：id、name、teacher_id
• 教師：id, name
• 課題：id、name、course_id
• スコア (学生と課題の間のピボットとして機能します): 学生ID、課題ID、スコア

私は、これらのテーブルのすべてについて、検索、作成、更新、および削除のメソッドを持つリポジトリクラスを持っています。各リポジトリには、データベースと対話する Eloquent モデルがあります。リレーションシップは、Laravelのドキュメントに従ってモデルで定義されています。 http://laravel.com/docs/eloquent#relationships .

新しいコースを作成する場合、私が行うことはコースリポジトリのcreateメソッドを呼び出すことだけです。そのコースには課題があり、課題を作成するとき、コースの各生徒のスコアテーブルにもエントリを作成したいです。私はこれを課題リポジトリを通して行います。これは、課題リポジトリが、課題モデルと学生モデルの2つのEloquentモデルと通信していることを意味します。

私の質問は：このアプリはおそらくサイズが大きくなり、より多くの関係が導入されるため、リポジトリで異なるEloquentモデルと通信することは良い習慣ですか、それともこれは代わりに他のリポジトリを使用して行われるべきですか（私はAssignmentリポジトリから他のリポジトリを呼び出すことを意味します）、またはそれはすべて一緒にEloquentモデルで行われるべきですか？

また、課題と学生の間のピボットとしてスコアテーブルを使用することは良い習慣ですか、それともどこか他の場所で行うべきですか？

どのように解決するのですか?

意見を求めていることに留意してください :D

これが私の意見です。

TL;DR: はい、それで結構です。

あなたは元気です!

私はあなたがやっていることをよくやっていて、とてもうまくいっていると思います。

しかし、私はしばしば、テーブルごとにリポジトリを持つのではなく、ビジネス ロジックを中心にリポジトリを整理します。これは、アプリケーションがどのようにビジネス上の問題を解決すべきかを中心に据えた視点であるため、便利です。

コースは属性 (タイトル、IDなど) および他のエンティティ (課題、それ自身の属性および場合によってはエンティティ) を持つ、quot;エンティティ" です。

あなたのquot;Course"リポジトリはコースおよびコースの属性/割り当て (割り当てを含む) を返すことができる必要があります。

幸運にもEloquentでそれを達成することができます。

(私はしばしばテーブルごとにリポジトリを持つことになりますが、いくつかのリポジトリは他のものよりはるかに多く使用されるため、より多くのメソッドを持ちます。例えば、アプリケーションがコースに重点を置き、コースの課題のコレクションに重点を置かない場合、quot;courses"リポジトリは課題リポジトリよりはるかにフルフィーチャーであるかもしれません）。

トリッキーな部分

私はよく、データベースの操作を行うために、リポジトリ内部でリポジトリを使用します。

データを処理するためにEloquentを実装しているリポジトリは、おそらくEloquentモデルを返すでしょう。この観点から、あなたのCourseモデルがAssignments（または他のユースケース）を取得または保存するためにビルトインリレーションシップを使用しても問題ないでしょう。私たちの実装はEloquentを中心に構築されています。

実用的な観点からは、これは理にかなっています。私たちは、Eloquentが処理できないもの(非SQLデータソース)にデータソースを変更することはまずありません。

ORMS

このセットアップの最も厄介な部分は、少なくとも私にとっては、Eloquent が実際に役立っているのか、それとも害を及ぼしているのかを判断することです。なぜなら、ORM は実用的な観点から大いに役立ちますが、ビジネス ロジック エンティティのコードとデータ検索を行うコードも結合するからです。

これは、リポジトリの責任が実際にデータを処理することなのか、それともエンティティ（ビジネスドメインエンティティ）の取得/更新を処理することなのかを混乱させるようなものです。

さらに、これらはビューに渡すオブジェクトそのものとして動作します。もし、リポジトリでEloquentモデルを使用することから離れなければならない場合、ビューに渡される変数が同じように動作するか、同じメソッドが利用可能であることを確認する必要があり、さもなければデータソースを変更すると、ビューも変更され、そもそもリポジトリに論理を抽象化する目的が（一部）失われ、プロジェクトの保守性が下がります。

とにかく、これらはやや不完全な考えです。これらは、前述のとおり、単に私の意見であり、たまたま ドメイン駆動設計 を読み、次のようなビデオを見た結果です。 ボブおじさんの基調講演 のようなビデオを見ています。