在 Laravel 5.8 中正确地应用 Repository 设计模式

在本文中,我会向你展示如何在 Laravel 中从头开始实现 repository 设计模式。我将使用 Laravel 5.8.3 版,但 Laravel 版本不是最重要的。在开始写代码之前,你需要了解一些关于 repository 设计模式的相关信息。

repository 设计模式允许你使用对象,而不需要了解这些对象是如何持久化的。本质上,它是数据层的抽象。

这意味着你的业务逻辑不需要了解如何检索数据或数据源是什么,业务逻辑依赖于 repository 来检索正确的数据。

关于这个模式,我看到有人将它误解为 repository 被用来创建或更新数据。 这不是 repository 应该做的,repository 不应该创建或更新数据,仅仅用于检索数据。

理解透了吧?接下来一起写代码

既然我们从头开始,那么我们先创建一个新的 Laravel 项目吧:

composer create-project --prefer-dist laravel/laravel repository

对于本教程,我们将构建一个小型的博客应用。现在我们已经创建好了一个新的 Laravel 项目,接下来应该为它创建一个控制器和模型。

php artisan make:controller BlogController

这将在 app/Http/Controllers 目录中创建 BlogController

php artisan make:model Models/Blog -m

提示:
-m 选项会创建一个对应的数据库迁移,你可以在 *database/migrations
目录中找到所生成的迁移。*

现在你应该能在 app/Models 目录中找到刚生成的模型 Blog 了吧。这只是一种我喜欢的存放模型的方式。

现在我们有了控制器和模型,是时候看看我们创建的迁移文件了。除了默认的 Laravel 时间戳字段外,我们的博客只需要 标题、内容用户ID 字段。

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateBlogsTable extends Migration
{
    public function up()
    {
        Schema::create('blogs', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('title');
            $table->text('content');
            $table->integer('user_id');
            $table->timestamps();

            $table->foreign('user_id')
                  ->references('id')
                  ->on('users');
        });
    }

    public function down()
    {
        Schema::dropIfExists('blogs');
    }
}

提示:
如果你使用的是 Laravel 5.8 以下的旧版本,请将

$table->bigIncrements('id');

替换为:

$table->increments('id');

设置数据库

我将使用 MySQL 数据库作为示例,第一步就是创建一个新的数据库。

mysql -u root -p 
create database laravel_repository;

以上命令将会创建一个叫 laravel_repository 的新数据库。接下来我们需要添加数据库信息到 Laravel 根目录的 .env 文件中。

DB_DATABASE=laravel_repository
DB_USERNAME=root
DB_PASSWORD=secret

当你更新了 .env 文件后我们需要清空缓存:

php artisan config:clear

运行迁移

现在我们已经设置好了数据库,可以开始运行迁移了:

php artisan migrate

这将会创建 blogs 表,包含了我们在迁移中声明的 title , contentuser_id 字段。

实现 repository 设计模式

一切就绪,我们现在可以开始实现 repository 设计风格了。我们将会在 app 目录中创建 Repositories 目录。我们将要创建的第二个目录是 Interfaces 目录,这个目录位于 Repositories 目录中。

Interfaces 文件中我们将创建一个包含两个方法的 BlogRepositoryInterface 接口。

  1. 返回所有博客文章的 all 方法
  2. 返回特定用户所有博客文章的 getByUser 方法
<?php

namespace App\Repositories\Interfaces;

use App\User;

interface BlogRepositoryInterface
{
    public function all();

    public function getByUser(User $user);
}

我们需要创建的最后一个类是将要实现 BlogRepositoryInterfaceBlogRepository ,我们会写一个最简单的实现方式。

<?php

namespace App\Repositories;

use App\Models\Blog;
use App\User;
use App\Repositories\Interfaces\BlogRepositoryInterface;

class BlogRepository implements BlogRepositoryInterface
{
    public function all()
    {
        return Blog::all();
    }

    public function getByUser(User $user)
    {
        return Blog::where('user_id',$user->id)->get();
    }
}

你的 Repositories 目录应该像这样:

app/
└── Repositories/
    ├── BlogRepository.php
    └── Interfaces/
        └── BlogRepositoryInterface.php

你现在已经成功创建了一个 repository 了。但是我们还没有完成,是时候开始使用我们的 repository 了。

在控制器中使用 Repository

要开始使用 BlogRepository ,我们首先需要将其注入到 BlogController 。由于 Laravel 的依赖注入,我们很容易用另一个来替换它。这就是我们控制器的样子:

<?php

namespace App\Http\Controllers;


use App\Repositories\Interfaces\BlogRepositoryInterface;
use App\User;

class BlogController extends Controller
{
    private $blogRepository;

    public function __construct(BlogRepositoryInterface $blogRepository)
    {
        $this->blogRepository = $blogRepository;
    }

    public function index()
    {
        $blogs = $this->blogRepository->all();

        return view('blog')->withBlogs($blogs);
    }

    public function detail($id)
    {
        $user = User::find($id);
        $blogs = $this->blogRepository->getByUser($user);

        return view('blog')->withBlogs($blogs);
    }
}

如你所见,控制器中的代码很简短,可读性非常的高。不需要十行代码就可以获取到所需的数据,多亏了 repository ,所有这些逻辑都可以在一行代码中完成。这对单元测试也很好,因为 repository 的方法很容易复用。

repository 设计模式也使更改数据源变得更加容易。在这个例子中,我们使用 MySQL 数据库来检索我们的博客内容。我们使用 Eloquent 来完成查询数据库操作。但是假设我们在某个网站上看到了一个很棒的博客 API,我们想使用这个 API 作为数据源,我们所要做的就是重写 BlogRepository 来调用这个 API 替换 Eloquent

RepositoryServiceProvider

我们将注入 BlogController 中的 BlogRepository ,而不是注入 BlogController 中的 BlogRepositoryInterface ,然后让服务容器决定将使用哪个存储库。这将在 AppServiceProviderboot 方法中实现,但我更喜欢为此创建一个新的 provider 来保持整洁。

php artisan make:provider RepositoryServiceProvider

我们为此创建一个新的 provider 的原因是,当您的项目开始发展为大型项目时,结构会变得非常凌乱。设想一下,一个拥有 10 个以上模型的项目,每个模型都有自己的 repository ,你的 AppServiceProvider 可读性将会大大降低。

我们的 RepositoryServiceProvider 会像下面这样:

<?php

namespace App\Providers;

use App\Repositories\BlogRepository;
use App\Repositories\Interfaces\BlogRepositoryInterface;
use Illuminate\Support\ServiceProvider;

class RepositoryServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->bind(
            BlogRepositoryInterface::class, 
            BlogRepository::class
        );
    }
}

留意用另一个 repository 替代 BlogRepository 是多么容易!

不要忘记添加 RepositoryServiceProviderconfig/app.php 文件的 providers 列表中。完成了这些后我们需要清空缓存:

'providers' => [
  \App\Providers\RepositoryServiceProvider::class
],
php artisan config:clear

就是这样

现在你已经成功实现了 repository 设计模式,不是很难吧?

你可以选择增加一些路由和视图来拓展代码,但本文将在这里结束,因为本文主要是介绍 repository 设计模式的。

如果你喜欢这篇文章,或者它帮助你实现了 repository 设计模式,请确保你也查看了我的其他文章。如果你有任何反馈、疑问,或希望我撰写另一个有关 Laravel 的主题,请随时发表评论。

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://itnext.io/repository-design-patt...

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

本帖已被设为精华帖!
本文为协同翻译文章,如您发现瑕疵请点击「改进」按钮提交优化建议
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 13
Summer

哈哈,之前团队有个同学 ,使用了 Repository ,项目开发一半,嫌麻烦改用原生的 Model,导致项目里有两种数据层的写法,后来他自己也不喜欢碰这个项目的代码了。

设计模式需要项目和团队成员的统一 ,否则只会添乱。

4年前
JaguarJack

:joy:这要是有几百个个仓库还不得累死 bind

4年前
fatrbaby

坚决不适用repository模式

4年前

虽然我已经在这样的基础上抽象了公用接口,但也没办法避免在Controller使用查询功能,因为Repository不适合复杂的查询操作,如果硬是在Repository写复杂查询就破坏了这种模式的初始想法,实在不利于开发复杂查询的功能

4年前
Summer

哈哈,之前团队有个同学 ,使用了 Repository ,项目开发一半,嫌麻烦改用原生的 Model,导致项目里有两种数据层的写法,后来他自己也不喜欢碰这个项目的代码了。

设计模式需要项目和团队成员的统一 ,否则只会添乱。

4年前
ibucoin

看项目习惯了,我就直接Controller和Model使用,需要多处复用的再进行抽离到service层。

4年前

上家公司就是要求这种写法,我们总监是java 出身的,因为php 开发快。但是这样写真的太怪了 ,好好的模型直接调用删除(自己脑补下别的方法),非要在过滤一下。大佬说照做就行,不敢问

4年前

Controller <=> Service <=> Repository <=> Model
更喜欢此模式,各执其职、各层之间抽离解耦。
每个人对于项目架构的认知不一,但在Team开发项目时,必须统一开发模式甚至是架构。

4年前 评论
AlicFeng (作者) 4年前
Joker-smile 4年前
anran 4年前
Joker-smile 4年前
AlicFeng (作者) 4年前
一念沧海一念桑田 4年前
AlicFeng (作者) 4年前
Egfly 4年前
WhiteDragon 4年前
AlicFeng (作者) 4年前
AlicFeng (作者) 4年前
dingdayu 4年前

这个和自己使用契约封装一个服务有什么区别吗?相比框架的契约实现,这里只是少了一层继承契约接口,写法更加简洁而已,另外实在是感觉不到repository有什么优势吗?如果只是对model的封装感觉大可不必了,感觉过度封装了

4年前 评论
李威 4年前
dingdayu 4年前
Destiny

过度的设计只会越来越麻烦。

4年前

长远看,有好处,项目活得够久的话,换数据源是极有可能的……

但是有几个项目能活到需要换数据源的时候呢…… :see_no_evil:

4年前
yourself

觉得分层多证明项目太小,要是没有必要分层,不如直接写在路由里面更清晰

4年前

我都是 Controller 里面直接调 Model,有啥弊端嘛?

4年前
Summer

出言不善的用户已屏蔽了!

因给大家都发送了通知,故这里解释下屏蔽原因:

  • 语出不善
  • 用户名乱码(fadsdsafcxz)
  • 头像轻浮(露骨美女照)
  • 0 积分(对社区未做过任何贡献,道不同不相为谋,可以到知乎)

技术人,应理智地讨论技术。戾气太重,讨论问题易演变为吵架。

4年前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!