管理Laravel的关系，坚持存储库模式 [英] Managing relationships in Laravel, adhering to the repository pattern

问题描述

我在Laravel 4中创建一个应用程序后，阅读了T. Otwell的Laravel中良好设计模式的书，发现自己为应用程序中的每个表创建了存储库。结束于以下表格结构：

• 学生：id，name


• 课程：名称，teacher_id


• 教师：id，name


• 作业：id，name，course_id


• 作为学生和作业之间的枢轴）：student_id，assignment_id，score

我有存储库类，包含查找，创建，更新和删除所有这些表的方法。每个存储库都有一个与数据库交互的Eloquent模型。关系在每个Laravel文档的模型中定义： http://laravel.com/docs/eloquent#relationships。

创建新课程时，我所做的就是在课程库中调用create方法。那个课程有作业，所以在创建一个时，我也想为课程中的每位学生创建分数表中的一个条目。我通过作业存储库这样做。这意味着分配存储库与两个高效的模型通信，分配和学生模型。

我的问题是：由于这个应用程序可能会在大小上增长，更多的关系将会介绍的是，在存储库中与不同的雄辩模型进行通信是好的做法，还是应该使用其他存储库来完成（我的意思是从分配存储库中调用其他存储库），还是应该在雄辩模型中完成？

另外，使用分数表作为作业和学生之间的枢纽还是应该在其他地方完成的好习惯？

解决方案

请记住，您正在征求意见：D

这是我的：

TL; DR：是的，没关系。

你没事！

我正在做你经常做的事情，发现它很好用。

然而，我经常组织资料库关于业务逻辑，而不是具有回购表。这是有用的，因为它是一个以您的应用程序如何解决您的业务问题为重点的观点。

课程是一个实体，具有属性（标题， id等），甚至其他实体（作业，有自己的属性和可能的​​实体）。

您的课程存储库应该能够返回一个课程，课程的属性/作业（包括作业）。

幸运的是，您可以用卓越的成就完成。

我经常结束每个表的存储库，但是一些存储库比其他存储库使用的更多，因此还有更多的方法。您的课程存储库可能比您的作业存储库更全面，例如，如果您的应用程序更多关于课程，更少关于课程的作业收集）。

棘手的部分

我经常在我的存储库内使用存储库，以便执行一些数据库操作。

为了处理数据，任何实现Eloquent的仓库都可能会返回Eloquent模型。在这方面，如果您的课程模型使用内置的关系来检索或保存作业（或任何其他用例），这很好。我们的执行是围绕着雄辩的。

从实际的角度来看，这是有道理的。我们不太可能将数据源更改为一个非常不能处理的东西（非SQL数据源）。

ORMS

至少对我来说，这个设置最棘手的部分是确定如果口才真的在帮助或伤害我们。 ORM是一个棘手的问题，因为虽然他们从实际的角度帮助我们，但他们也将您的业务逻辑实体代码与执行数据检索的代码相结合。

这种混乱是否您的存储库的责任实际上是处理数据或处理实体（业务域实体）的检索/更新。

此外，它们的作用你传递给你的意见的对象。如果您以后不得不在存储库中使用Eloquent模型，则需要确保传递给您的视图的变量以相同的方式运行或具有相同的方法可用，否则更改数据源将会变为意见，您（部分）失去了将逻辑抽象出来到存储库的目的 - 您的项目的可维护性下降。

无论如何，这些有些不完整的想法。正如所述，他们只是我的意见，恰好是阅读域驱动设计并观看视频的结果像过去一年的Ruby Midwest的叔叔鲍勃的主题演讲。

While creating an app in Laravel 4 after reading T. Otwell's book on good design patterns in Laravel I found myself creating repositories for every table on the application.

I ended up with the following table structure:

• Students: id, name
• Courses: id, name, teacher_id
• Teachers: id, name
• Assignments: id, name, course_id
• Scores (acts as a pivot between students and assignments): student_id, assignment_id, scores

I have repository classes with find, create, update and delete methods for all of these tables. Each repository has an Eloquent model which interacts with the database. Relationships are defined in the model per Laravel's documentation: http://laravel.com/docs/eloquent#relationships.

When creating a new course, all I do is calling the create method on the Course Repository. That course has assignments, so when creating one, I also want to create an entry in the score's table for each student in the course. I do this through the Assignment Repository. This implies the assignment repository communicates with two Eloquent models, with the Assignment and Student model.

My question is: as this app will probably grow in size and more relationships will be introduced, is it good practice to communicate with different Eloquent models in repositories or should this be done using other repositories instead (I mean calling other repositories from the Assignment repository) or should it be done in the Eloquent models all together?

Also, is it good practice to use the scores table as a pivot between assignments and students or should it be done somewhere else?

解决方案

Keep in mind you're asking for opinions :D

Here's mine:

TL;DR: Yes, that's fine.

You're doing fine!

I do exactly what you are doing often and find it works great.

I often, however, organize repositories around business logic instead of having a repo-per-table. This is useful as it's a point of view centered around how your application should solve your "business problem".

A Course is a "entity", with attributes (title, id, etc) and even other entities (Assignments, which have their own attributes and possibly entities).

Your "Course" repository should be able to return a Course and the Courses' attributes/Assignments (including Assignment).

You can accomplish that with Eloquent, luckily.

(I often end up with a repository per table, but some repositories are used much more than others, and so have many more methods. Your "courses" repository may be much more full-featured than your Assignments repository, for instance, if your application centers more around Courses and less about a Courses' collection of Assignments).

The tricky part

I often use repositories inside of my repositories in order to do some database actions.

Any repository which implements Eloquent in order to handle data will likely return Eloquent models. In that light, it's fine if your Course model uses built-in relationships in order to retrieve or save Assignments (or any other use case). Our "implementation" is built around Eloquent.

From a practical point of view, this makes sense. We're unlikely to change data sources to something Eloquent can't handle (to a non-sql data source).

ORMS

The trickiest part of this setup, for me at least, is determing if Eloquent is actually helping or harming us. ORMs are a tricky subject, because while they help us greatly from a practical point of view, they also couple your "business logic entities" code with the code doing the data retrieval.

This sort of muddles up whether your repository's responsibility is actually for handling data or handling the retrieval / update of entities (business domain entities).

Furthermore, they act as the very objects you pass to your views. If you later have to get away from using Eloquent models in a repository, you'll need to make sure the variables passed to your views behave in the same way or have the same methods available, otherwise changing your data sources will roll into changing your views, and you've (partially) lost the purpose of abstracting your logic out to repositories in the first place - the maintainability of your project goes down as.

Anyway, these are somewhat incomplete thoughts. They are, as stated, merely my opinion, which happens to be the result of reading Domain Driven Design and watching videos like "uncle bob's" keynote at Ruby Midwest within the last year.

这篇关于管理Laravel的关系，坚持存储库模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！