2017-04-05 73 views
0

我目前正在使用lumen创建一个API,我并不完全有信心应该将数据库查询放在哪里。我使用Repository模式,目前我的布局就像这样:使用存储库模式将Laravel查询放在哪里

  1. 控制器加载自定义库
  2. 库方法包含雄辩查询并返回结果。

Controller --> Custom Repository --> Model

Controller <-- Custom Repository <-- Model

- 的我当前如何做一个高层次的代码示例:

Controller.php这样

public function browse() 
{ 
    // customRepo added via dependency injection 
    $this->customRepo->browse() 
} 

customRepo.php

public function browse() 
{ 
    // other logic here 
    return Member::where('active', 1)->orderBy('date', 'desc')->get() 
} 

我使用Eloquent来查询数据库,目前所有这些调用都发生在Repository中,这对我来说有点奇怪,因为我的Repositories填充了Eloquent(和一些查询生成器)查询我从几个来源看到它是not correct将查询放入模型中。

我觉得我现在的方法可能是正确的我只是想看看是否有人可以明确地告诉我哪个是最好的 - 如果没有,我用自定义方法填充模型没有太大意义需要。

回答

1

需要考虑的几点。首先,对术语进行一些澄清。您已经举例说明的存储库模式实际上并不是Repository pattern。这更像是一个Data Access Object pattern。请参阅quentin-starin's answer以了解两者之间差异的简要说明。其次,MVC体系结构中的模型不仅仅是一个扩展(在这种情况下为Eloquent的)模型类的类。有很多关于它的文章,但为了简洁起见,该模型通常是MVC应用程序的一个组合部分,它处理除了域/业务逻辑之外的数据管理。我将使用术语实体来指代您创建的特定的基于Eloquent的类(例如 - 成员)。鉴于这种理解(对于代码重用/松散耦合/等),在模型中放置任何查询当然是有益的。但不直接在你的实体中处理数据持久性是一个好主意。剩下的问题是,“我应该如何访问模型和/或实体?”。

我看到并使用过的一种方法是直接从控制器调用存储库/ DAO的方法。为了可测试性,这通常通过将有问题的实体实例注入到存储库类来完成。例如,您的customRepo.php文件中,你可以创建一个类似于下面的内容:

protected $model; 

public function __construct(\App\Member $model) 
{ 
    $this->model = $model; 
} 

public function getActiveMembers() 
{ 
    return $this->model->where('active', 1)->orderBy('date', 'desc')->get() 
} 

另一种方法是通过一个服务层来创建控制器和存储库之间抽象的附加层,其中到资源库中调用/等等。将居住。这个服务层可以是一个地方,可以激发域事件,在数据库事务中包装多种数据访问方法等。我个人的方法是当我认识到他们的需要和/或开始违反SOLID原则时,创建新的抽象层。在那之前,KISS

0

把你的查询放到版本库中,就像你在做的一样,在我看来是正确的,而不是违反了你不应该把查询放在模型中的想法。换句话说,我觉得你在混合存储库和模型的概念。

存储库是一袋特定类型的东西,并知道如何存储和检索这个包中的物品。

模型包含很少或没有功能,除了业务逻辑正确处理模型的属性(计算属性想到)。