在 Laravel 中管理关系，遵循存储库模式 [英] Managing relationships in Laravel, adhering to the repository pattern

问题描述

在阅读 T. Otwell 关于 Laravel 良好设计模式的书后，在 Laravel 4 中创建应用程序时，我发现自己为应用程序中的每个表创建了存储库.

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:

• 学生:身份证、姓名
• 课程:id、name、teacher_id
• 教师:id、姓名
• 作业:id、name、course_id
• 分数(作为学生和作业之间的支点):student_id、assignment_id、scores

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

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.

创建新课程时，我所做的只是调用课程存储库上的 create 方法.该课程有作业，因此在创建作业时，我还想为课程中的每个学生在分数表中创建一个条目.我通过作业存储库执行此操作.这意味着作业存储库与两个 Eloquent 模型进行通信，即作业和学生模型.

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.

我的问题是:由于这个应用程序的规模可能会越来越大并且会引入更多的关系，在存储库中与不同的 Eloquent 模型进行通信是一种好习惯，还是应该使用其他存储库来完成(我的意思是从分配存储库)还是应该一起在 Eloquent 模型中完成?

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?

推荐答案

记住你是在征求意见 :D

Keep in mind you're asking for opinions :D

这是我的:

我做的正是你经常做的事情，并且发现它非常有效.

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".

课程是一个实体"，具有属性(标题、ID 等)甚至其他实体(作业，它们具有自己的属性和可能的​​实体).

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).

幸运的是，您可以使用 Eloquent 实现这一点.

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).

我经常在我的存储库中使用存储库来执行一些数据库操作.

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

任何实现 Eloquent 以处理数据的存储库都可能返回 Eloquent 模型.从这个角度来看，如果您的 Course 模型使用内置关系来检索或保存作业(或任何其他用例)，那很好.我们的实现"是围绕 Eloquent 构建的.

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.

从实用的角度来看，这是有道理的.我们不太可能将数据源更改为 Eloquent 无法处理的内容(更改为非 sql 数据源).

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).

这个设置中最棘手的部分，至少对我来说，是确定 Eloquent 是否真的在帮助或伤害我们.ORM 是一个棘手的主题，因为虽然它们从实践的角度来看对我们有很大帮助，但它们还将您的业务逻辑实体"代码与执行数据检索的代码相结合.

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).

此外，它们充当传递给视图的对象.如果您以后不得不在存储库中使用 Eloquent 模型，则需要确保传递给视图的变量以相同的方式运行或具有相同的可用方法，否则更改数据源将导致更改您的数据源视图，并且您(部分)失去了将逻辑抽象到存储库的目的 - 您的项目的可维护性下降了.

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.

总之，这些都是有些不完整的想法.如前所述，它们只是我的意见，这恰好是阅读 域驱动设计 并观看鲍勃叔叔"主题演讲等视频去年在 Ruby Midwest 工作.

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屋！