Question

我目前正在使用lumen创建API，而且我对完成数据库查询的位置并不完全有信心。我正在使用Repository模式，目前我的布局是这样的：

控制器加载自定义存储库
Repository方法包含eloquent查询并返回结果。

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中，这对我来说有点奇怪，因为我的存储库正在填充Eloquent（和一些查询构建器）查询但是我有从一些消息来源看，它是not correct将查询放入模型中。

我觉得我目前的方法可能是正确的我只是想看看是否有人能明确地告诉我哪个是最好的 - 如果我用自定义方法填充模型，那么这对我来说并没有多大意义。不需要。

Answer 1

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

我见过和使用的一种方法是直接从控制器调用存储库/ DAO方法。为了可测试性，这通常通过将有问题的实体的实例注入存储库类来实现。例如，在customRepo.php文件中，您可以创建类似于以下内容的内容：

tabset

另一种方法是通过服务层在控制器和存储库之间创建一个额外的抽象层，其中调用存储库/ etc。将驻留。这个服务层可以是一个触发域事件，在数据库事务中包装多个数据访问方法等的地方。我个人的方法是在我认识到需要它们和/或开始违反{{3}时创建新的抽象层。 } 原则。在那之前，SOLID。

Answer 2

在我看来，将您的查询放在存储库中是正确的，并且不违反您不应该在模型中放置查询的想法。换句话说，我觉得你正在混合存储库和模型的概念。

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

除了业务逻辑之外，模型几乎不包含任何功能，无法正确处理模型的属性（计算属性时会想到）。

使用存储库模式

2 个答案: