Explain in detail what is the use of the repository pattern (Repository) in Laravel?-Laravel-php.cn

Repository Pattern in Laravel

Why use the repository pattern in Laravel?

In my previous article I explained what the repository pattern is, how it differs from the Active Record pattern, and how to implement it in Laravel it. Now I want to take a closer look at why you should use the repository pattern.

I noticed in the comments of the previous article that the Repository pattern is a controversial topic in the Laravel community. Some people see no reason to use it and stick with the built-in Active Record mode. Others prefer to use other methods to separate data access from the logical domain. Please note that I respect these opinions and will devote an upcoming blog post to this topic.

With this disclaimer, let’s understand the advantages of using the repository pattern. [Related tutorial recommendations: laravel]

Single Responsibility Principle

The single responsibility principle is the main discriminator to distinguish Active Record mode and repository mode . Model classes already hold data and provide methods on domain objects. When using the Active Record pattern, data access is an additional responsibility introduced. This is something I want to illustrate in the following example:

/**
 * @property string $first_name
 * @property int    $company_id
 */
class Employee extends Model {}

$jack = new Employee();
$jack->first_name = &#39;Jack&#39;;
$jack->company_id = $twitterId;
$jack->save();

Copy after login

Although the domain model and data access technology have mixed responsibilities, it intuitively makes sense. In our application the employees have to be stored in the database somehow, so why not call save() on the object. A single object is converted into a single row of data and stored.

But let's go a step further and see what else we can do with employees:

$jack->where(&#39;first_name&#39;, &#39;John&#39;)->firstOrFail()->delete();
$competition = $jack->where(&#39;company_id&#39;, $facebookId)->get();

Copy after login

Now, it becomes unintuitive and even violates our domain model. Why would Jack suddenly delete another employee who might even be working at a different company? Or why he was able to bring Facebook employees over?

Of course, this example is contrived, but it still shows how the Active Record pattern does not allow for intentional domain models. The line between employees and the list of all employees becomes blurred. You always have to consider whether the employee is being used as an actual employee or as a mechanism to access other employees.

Warehouse mode solves this problem by enforcing this basic partitioning. Its only purpose is to identify a collection of domain objects, not the domain object itself.

Key points:

#The warehouse pattern embodies the single responsibility principle by separating a collection of all domain objects from a single domain object.

Don’t Repeat Yourself (DRY)

Some projects sprinkle database queries all over the project. Below is an example where we get a list from the database and display them in a Blade view.

class InvoiceController {

    public function index(): View {
        return view(&#39;invoices.index&#39;, [
            &#39;invoices&#39; => Invoice::where(&#39;overdue_since&#39;, &#39;>=&#39;, Carbon::now())
                ->orderBy(&#39;overdue_since&#39;)
                ->paginate()
        ]);
    }}

Copy after login

When a query like this becomes more complex and used in multiple places, consider extracting it into a Repository method.

The repository pattern helps reduce duplicate queries by packaging them into expression methods. If you have to adjust the query, you only need to change it once.

class InvoiceController {

    public __construct(private InvoiceRepository $repo) {}

    public function index(): View {
        return view(&#39;invoices.index&#39;, [
            &#39;invoices&#39; => $repo->paginateOverdueInvoices()
        ]);
    }}

Copy after login

Now the query is implemented only once and can be tested in isolation and used elsewhere. Additionally, the Single Responsibility Principle comes into play again, as the controller is not responsible for getting the data, but only for processing the HTTP request and returning the response.

Takeaway:

Dependency Inversion

Explaining the Dependency Inversion Principle deserves its own blog post. I just wanted to illustrate that a repository can enable dependency inversion.

When layering components, typically higher-level components depend on lower-level components. For example, the controller will rely on the model class to get data from the database:

class InvoiceController {
    public function index(int $companyId): View {
        return view(
            &#39;invoices.index&#39;,
            [&#39;invoices&#39; => Invoice::where(&#39;company_id&#39;, $companyId)->get()]
        );
    }}

Copy after login

The dependency is top-down and tightly coupled.

InvoiceController depends on the specific Invoice class. It is difficult to decouple these two classes, such as testing them separately or replacing the storage mechanism. By introducing the Repository interface, we can achieve dependency inversion:

interface InvoiceRepository {
    public function findByCompanyId($companyId): Collection;}class InvoiceController {
    public function __construct(private InvoiceRepository $repo) {}

    public function index(int $companyId): View {
        return view(
            &#39;invoices.index&#39;,
            [&#39;invoices&#39; => $this->repo->findByCompanyId($companyId)]
        );
    }}class EloquentInvoiceRepository implements InvoiceRepository {
    public function findByCompanyId($companyId): Collection {
        // 使用 Eloquent 查询构造器实现该方法
    }}

Copy after login

Controller now only depends on the Repository interface, the same as the Repository implementation.

These two classes now only depend on one abstraction, thus reducing Coupling. As I will explain in the next section, this brings further advantages.

Takeaway:

存储库模式作为一种抽象类，支持依赖反转.

抽象类

存储库 提高了可读性 因为复杂的操作被具有表达性名称的高级方法隐藏了.

访问存储库的代码与底层数据访问技术分离. 如有必要,您可以切换实现，甚至可以省略实现，仅提供 Repository 接口。这对于旨在与框架无关的库来说非常方便。

OAuth2 服务包 —— league/oauth2-server 也用到这个抽象类机制。 Laravel Passport 也通过实现这个库的接口集成 league/oauth2-server 包。

正如 @bdelespierre 在评论里回应我之前的一篇博客文章时向我指出的那样，你不仅可以切换存储库实现，还可以将它们组合在一起。大致以他的示例为基础，您可以看到一个存储库如何包装另一个存储库以提供附加功能：

interface InvoiceRepository {
    public function findById(int $id): Invoice;}class InvoiceCacheRepository implements InvoiceRepository {

    public function __construct(
        private InvoiceRepository $repo,
        private int $ttlSeconds
    ) {}

    public function findById(int $id): Invoice {
        return Cache::remember(
            "invoice.$id",
            $this->ttlSeconds,
            fn(): Invoice => $this->repo->findById($id)
        );
    }}class EloquentInvoiceRepository implements InvoiceRepository {

    public function findById(int $id): Invoice { /* 从数据库中取出 $id */ }}// --- 用法:$repo = new InvoiceCacheRepository(
    new EloquentInvoiceRepository(););

Copy after login

要点:

存储库模式抽象了有关数据访问的详细信息。
存储库将客户端与数据访问技术分离。
这允许切换实现，提高可读性并实现可组合性。

可测试性

存储库模式提供的抽象也有助于测试。

如果你有一个 Repository 接口，你可以提供一个替代的测试实现。您可以使用数组支持存储库，而不是访问数据库，将所有对象保存在数组中：

class InMemoryInvoiceRepository implements InvoiceRepositoryInterface {

    private array $invoices;

    // implement the methods by accessing $this->invoices...
    }
    // --- Test Case:
    $repo = new InMemoryInvoiceRepository();
    $service = new InvoiceService($repo);

Copy after login

通过这种方法，您将获得一个现实的实现，它速度很快并且在内存中运行。但是您必须为测试提供正确的 Repository 实现，这 ** 本身可能需要大量工作**。在我看来，这在两种情况下是合理的：

1.您正在开发一个（与框架无关的）库，它本身不提供存储库实现。

2.测试用例复杂，Repository 的状态很重要。

另一种方法是“模仿”，要使用这种技术，你不需要适当的接口。你可以模仿任何 non-final 类。
使用 PHPUnit API ，您可以明确规定如何调用存储库以及应该返回什么。

$companyId = 42;

/** @var InvoiceRepository&MockObject */
$repo = $this->createMock(InvoiceRepository::class);

$repo->expects($this->once())
    ->method(&#39;findInvoicedToCompany&#39;)
    ->with($companyId)
    ->willReturn(collect([ /* invoices to return in the test case */ ]));

$service = new InvoiceService($repo);

$result = $service->calculateAvgInvoiceAmount($companyId);

$this->assertEquals(1337.42, $result);

Copy after login

有了 mock，测试用例就是一个适当的单元测试。上面示例中测试的唯一代码是服务。没有数据库访问，这使得测试用例的设置和运行非常快速。

另外:

仓库模式允许进行适当的单元测试，这些单元测试运行快并且是隔离的。

原文地址：https://dev.to/davidrjenni/why-use-the-repository-pattern-in-laravel-2j1m

译文地址：https://learnku.com/laravel/t/62521

The above is the detailed content of Explain in detail what is the use of the repository pattern (Repository) in Laravel?. For more information, please follow other related articles on the PHP Chinese website!