"修饰"(Decorate)Laravel里面的Repositories

该篇属于[《Laravel底层核心技术实战揭秘》]; 欢迎作客我们的php&Laravel学习群:109256050(//study.163.com/course/courseMain.htm?courseId=1003575006)这一课程《laravel底层核心概念解析》这一章的扩展阅读。考虑到学员们的基础差异,为了避免视频当中过于详细而连篇累牍,故将一些laravel底层实现相关的PHP知识点以文章形式呈现,供大家预习和随时查阅。
原文链接: http://www.pilishen.com/posts...

像我们之前在课程里提到的,当开发任何正式的laravel项目时,将controller与我们的Eloquent ORM(或者其他的数据来源)进行解耦,向来是老练明智之举。通常我们会创建一个interface,然后再写一个实现了这个interface的repository,然后再通过laravel服务容器将对该interface的依赖解析到这个具体的repository上,具体的数据操作我们都是在repository当中进行。

同样的道理也适用于cache。我们都知道,数据查询往往是我们一个web应用里的主要性能瓶颈,所以难免要为数据查询创建相应的缓存(cache)。同样的,在你的controller里面具体地实现数据cache,也是非常糟糕的做法——这样呢,你就将controller与某一种特定的cache实现给强行绑到一块了,后期如果你想着换一种实现方式,比如从memcache换成redis,那么你就不得不大量修改你controller里的逻辑。而且,当某一个数据查询在多个地方出现时,你就不得不写重复的cache实现的代码。

或许呢,你可以在你的repository里写cache相关的实现逻辑,对相对较小的项目,这样倒也行得通。但是呢,这也意味着你的repository就既依赖于ORm,又依赖于你所选择的cache。这个时候如果你想着更换其中任何一种依赖形式,都很可能意味着你得重新写一整个新的repository,这期间又要重复很多之前的代码。

当然,肯定有一个更优雅的方式——通过使用“修饰者模式”(decorator pattern),我们可以再创建一个repository,让其实现同一个interface,同时呢,把之前那个repository里的实现给“包裹”起来,或者说“修饰”一下。在这个cache相关的repository里,每一个方法内都相应调取之前那个数据repository里的逻辑,然后相应地返回cache过后的response。这样的话,我们cache的逻辑,就跟我们数据操作的逻辑,相对分离开了,假设后期我们想换一种数据来源,那么我们的cache实现也就不会受到影响。

假设这是对应于我们Usermodel的interface:

接下来呢是其对应的数据操作的repository:

model = $model;
    }
    public function all()
    {
        return $this->model->all();
    }
    public function findOrFail($id)
    {
        return $this->model->findOrFail($id);
    }
    public function create($input)
    {
        $user = new $this->model;
        $user->email = $input['email'];
        $user->name = $input['name'];
        $user->password = Hash::make($input['password']);
        $user->save();
        return $user;
    }
}

我们可以这样来定义一个cache repository:

repository = $repository;
        $this->cache = $cache;
    }
    public function all()
    {
        return $this->cache->tags('users')->remember('all', 60, function () {
            return $this->repository->all();
        });
    }
    public function findOrFail($id)
    {
        return $this->cache->tags('users')->remember($id, 60, function () use ($id) {
            return $this->repository->findOrFail($id);
        });
    }
    public function create($input)
    {
        $this->cache->tags('users')->flush();
        return $this->repository->create($input);
    }
}

可以看到我们的这个cache repository里每个方法,实际上并不负责任何的数据查询操作。我们通过constructor接收一个同样实现了该interface的具体实现类,也即之前的数据查询的repository,同时接收cache服务,这样呢,我们不需要触碰任何的数据查询逻辑,直接调取数据相关的repository里相应的方法,然后给它相应地“包裹”上cache即可,或者说用cache实现“修饰”了一下之前的数据查询结果。

那么要实际地调用到我们的这个cache实现,我们还需要更新一下我们的service provider,好让它把这个“修饰者”,也即我们的cache repository,给相应地解析出来:

app->singleton('App\Repositories\Interfaces\UserRepositoryInterface', function () {
            $baseRepo = new \App\Repositories\EloquentUserRepository(new \App\User);
            $cachingRepo = new \App\Repositories\Decorators\CachingUserRepository($baseRepo, $this->app['cache.store']);
            return $cachingRepo;
        });
    }
}

可以看到我们实例化了数据查询的repository,也即$baseRepo,然后实例化cache repository,将数据repository和cache服务传递进去,然后返回这个cache repository的实例。这样了以后,我们就可以在controller里实际调用了。

注意的是,用cache repository来“装饰”原本的数据repository,这只是一个例子、一种用法而已,希望通过这个,你能学会的是如何“装饰、修饰”你的已有的数据repository,不止是cache实现,比如也可以在装饰者中触发特定事件。

你可能感兴趣的:(interface,repository,laravel)