通过 Eloquent 实现 Repository 模式 - 简书

胖胖的Eloquent

Eloquent采用了ActiveRecord的模式,这也让Eloquent招致了好多批评,让我们去看现在Eloquent/Model.php文件, 该文件已经有3500多行,此时的Model集成了太多的功能了,一个新人很难短时去理解Model并去很好的使用了,目前Eloquent/Model中主要混合了4个功能:

  1. Domain Model(包括了data model和领域逻辑)
  2. Row Data Gateway(例如save,delete等数据持久化操作)
  3. Table data gateway(各种find方法)
  4. Factory(新建model)

上面介绍的几种ORM设计模式,可以去之前的文章查看:orm 系列 之 常用设计模式

我们可以看到Model中混合了各种模式,这就要求使用者在使用的时候清楚的知道怎么使用,这里的清楚知道怎么用是指根据SOILD原则,优雅的使用Model,本文的目的就是帮助Model的使用者达成优雅的目标。

那理想的Model使用是什么样子的呢?我们希望Model的使用不是ActiveRecord,而是较为清晰的DataMapper模式,能够让domain model和database解耦,然后由DataMapper来完成映射工作,更具体点,我们希望的是像clean architecture中定义的架构一样,内层是Domain Model,外面是Domain Services,Domain Services又可以具体分为:

  • Repositories

    服务领域对象的存取,如果后端是数据库,就是负责将数据从数据库中取出,将对象存入数据库。

  • Factories

    负责对象的创建。

  • Services

    具体的业务逻辑,通过调用多个对象和其他服务来完成一个业务目标。

由此实现很好的解耦和关注点分离,更具体的关注clean architecture可以查看简书专题:clean architecture.

Eloquent拆解

讲述了一些方法论后,我们来动手实作一下

talk is cheap, show me the code

第一步,我们定义一个member表

php artisan make:migration MemberCreate

第二步,编写表定义

Schema::create('members',function(Blueprint $table){
    $table->increments('id');
    $table->string('login_name');
    $table->string('display_name');
    $table->integer('posts')->unsigned();
});

第三步,执行migration

php artisan migrate

第四步,生成model文件

php make:model Member

下面开始定义一些接口

The Member Model Interface

interface MemberInterface
{
    public function getID();
    public function getLoginName();
    public function getDisplayName();   
    public function getPostCount();
    public function incrementPostCount();
    public function decrementPostCount();
}

The Eloquent Member Model Implementation

class Member extends Model implements MemberInterface
{
    const ATTR_DISPLAY_NAME = ‘display_name’;
    const ATTR_LOGIN_NAME = ‘login_name’;
    const ATTR_POST_COUNT = ‘posts’;

    protected $fillable = [
        self::ATTR_LOGIN_NAME,
        self::ATTR_DISPLAY_NAME
    ];
    public function getID()
    {
        return $this->getKey()
    }
    public function getLoginName()
    {
        return $this->{self::ATTR_LOGIN_NAME};
    }

    public function getDisplayName()
    {
        return $this->{self::ATTR_DISPLAY_NAME};
    }

    public function getPostCount()
    {
        return $this->{self::ATTR_POST_COUNT};
    }

    public function incrementPostCount()
    {
        $this->{self::ATTR_POST_COUNT}++;
    }
    public function decrementPostCount()
    {
        if ($this->getPostCount() > 0) {
            $this->{self::ATTR_POST_COUNT}--;
        }
    }
}

The Member Repository Interface

interface MemberRepositoryInterface
{
   public function find($id);
   public function findTopPosters($count = 10);
   public function save(MemberInterface $member);
}

The Eloquent Member Repository Implementation

class EloquentMemberRepository implements MemberRepositoryInterface {
    /** @var  Member */
    protected $model;

    /**
     * EloquentMemberRepository constructor.
     *
     * @param \App\Member $model
     */
    public function __construct( Member $model )
    {
        $this->model = $model;
    }

    public function find( $id )
    {
        return $this->model->find($id);
    }

    /**
     * @param int $count
     *
     * @return \Illuminate\Support\Collection
     */
    public function findTopPosters( $count = 10 )
    {
        return $this->model
            ->orderBy(($this->model)::ATTR_POST_COUNT, 'DESC')
            ->take($count)
            ->get();
    }

    public function save( MemberInterface $member )
    {
        $member->save();
        /*
      注意:此处我们接口声明上是 MemberInterface ,这个是普适的规则
        但是此处的 Eloquent 实现是基于 Eloquent Model的,因此假设 传入的
        MemberInterface 实现了 save 方法
      */
    }
}

基本使用

DemonstrationController
{
    public function createPost(MemberRepositoryInterface $repository)
    {
        // validate request, create the post, and...
        $member = Auth::user()->member();
        $member->incrementPostCount();
        $respository->save($member);
    }
    public function deletePost(MemberRepositoryInterface $repository)
    {
        // validate request, delete the post, and...
        $member = Auth::user()->member();
        $member->decrementPostCount();
        $respository->save($member);
     }
    public function dashboard(MemberRespositoryInterface $repository)
    {
        $members = $repository->findTopPosters(20);
        return view('dashboard', compact('members'));
    }
}

使用的时候我们看到了好的方式,那如果我们没有定义repository和interface,会怎么样呢?

DemonstrationController
{
    public function createPost()
    {
        // validate request, create the post, and...
        $member = Auth::user()->getMember();
        $member->posts++;
        $member->save();
    }
    public function deletePost()
    {
        // validate request, delete the post, and...
        $member = Auth::user()->getMember();
        if ($member->posts > 0) {
            $member->posts--;
            $member->save();
        }
    }
    public function dashboard()
    {
        $members = Member::orderBy('posts', 'DESC')->take(20)->get(); 
        return view('dashboard', compact('members'));
    }
}

上面简单的业务逻辑posts不能小于0,都没有很好的封装,如果上面我们一些增加和减少的功能和save封装到一起呢?

DemonstrationController
{
    public function createPost()
    {
        // validate request, create the post, and...
        $member = Auth::user()->member();
        $member->incrementPostCount();
    }
    public function deletePost()
    {
        // validate request, delete the post, and...
        $member = Auth::user()->member();
        $member->decrementPostCount();
    }
}
class Member extends Model implements MemberInterface
{
    //...


    public function incrementPostCount()
    {
        $this->{self::ATTR_POST_COUNT}++;
        $this->save();
    }
    public function decrementPostCount()
    {
        if ($this->getPostCount() > 0) {
            $this->{self::ATTR_POST_COUNT}--;
            $this->save();
        }
    }

    // ...
}

这样做主要有两个问题

  1. 如果我们将Model的实现由Eloquen转换为其他呢?这将会使应用出错
  2. 我们每个更改都是执行一个sql语句,严重浪费,我们完全可以做完更改后,统一一次update

通过上面的对比,我们更能发现使用Repository和Interface的好处,能让我们更好的实现关注点分离,下面我们会更深入的讨论一些问题:包括Collections, Relations, Eager Loading, 和 Schema Changes。

Eloquent进阶

首先介绍collection的问题,看代码

class FooController
{
   public function bar(PostRepositoryInterface $repository)
   {
      $posts = $repository->findActivePosts();
      $posts->load('author');
   }
}

上面的代码中,虽然我们使用的type hint表明使用的repository是PostRepositoryInterface,但是方法findActivePosts返回的collection显然是跟Eloquent耦合的Eloquent\Collection,那怎么解决这个问题呢?有以下几个方案

  1. findActivePosts返回Collection,而不是Eloquent\Collection,避免在Repository之外使用Eloquent相关的功能
  2. 通过custom collections方法,返回自定义的collection

下面介绍第二个议题Eager Loading

还是看代码

class FooController
{
   public function bar(PostRepositoryInterface $repository)
   {
      $posts = $repository->findActivePosts(['author']);
   }
}

上面的代码通过参数[‘author’]的传入,将eager loading的操作封装在了findActivePosts之内,但是这样子做,反而让调用方必须知道实现细节,即本来是功能上的优化,通过eager loading来解决N+1问题的方案,变为了业务需要知道的业务的逻辑了,明显是不合理的。

更可怕的时候,你可能会希望通过传入参数让findActivePosts实现更多的功能,于是变为了下面的函数findActivePostsInDateRange($start, $end, $eagerLoading = null),我们看到随着项目复杂度的提升,我们不得不通过通过参数来满足更多的需求,但是这也使得接口变得更复杂,功能更多,到最后我们不得不面对各种ugly的代码,那面对Eager Loading我们到底应该怎么办呢?下面给出一个建议:

在提供非eager loading的方法同时,提供一个eager loading的方法。这可能会被人说:这也不是让用户知道了实现细节了嘛。是的,这方法是一个性能和使用上的妥协。

最后介绍Relations,看到代码

interface MemberInterface
{
   public function getID();
   public function getLoginName();
   public function getDisplayName();   
   public function getPostCount();
   public function incrementPostCount();
   public function decrementPostCount();
   public function getPosts();
   public function getFavoritePosts();
}
class Member extends Model implements MemberInterface
{
   ...

   public function posts()
   {
      return $this->hasMany(Post::class);
   }

   public function getPosts()
   {
       return $this->posts;
   }

   public function getFavoritePosts()
   {
       // I think this will work!
       return $this->posts()
                   ->newQuery()
                   ->whereHas('favorites', function($q) {
                        $q->where(Favorite::ATTR_MEMBER_ID, $this->getID()); 
                     })->get();
   }

   ...
}

我们没有办法将relation Method设置为protect或者private(这样设置的目的是让外面不使用,限制使用范围),但是这样子会导致想whereHas这种方法执行不成功。

此处还注意到一个问题,我们此时使用的posts是表示relation,但是之前是member的一个字段,明显冲突了,我们需要修改字段名,从postspost_count,因为我们之前使用了常量来定义属性,因此只需要下面一行代码就解决问题了:

const ATTR_POST_COUNT = ‘post_count’;

总结

介绍了这么多,我们解决了一个核心问题:因为Eloquent的功能耦合,我们应该正确的使用它,Eloquent的ActiveRecord模式可以让我们非常容易的实现DataMapper,根据Clean architecture的定义,我们将domain services分为了Repositories,Factories,Services,实现了关注点分离。

但是到目前,还有一个问题没有解决,那就是通过Repository,我们很难实先Eloquent/Builder那样丰富的查询功能,我们不得不每次新增一个查询条件,就去新增接口或者参数,不慎其烦,就像之前的findActivePostsInDateRange方法一样丑陋,那到底有什么办法解决呢?尽情期待下一篇内容,Repository的实作。

参考

Separation of Concerns with Laravel’s Eloquent Part 1: An Introduction

    原文作者:算法小白
    原文地址: https://juejin.im/entry/5846345a61ff4b006ba5c450
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞