当服务类可以做同样的事情时，存储库的目的是什么？

Question

通常我将逻辑放在服务类中而不使用存储库，例如，像这样：

namespace App\ProjectName\Profile;

use App\User;

class AccountService
{
    private $userModel;

    public function __construct(User $userModel)
    {
        $this->userModel = $userModel;
    }

    public function detail()
    {
        $user = \Auth::User();

        return [
            'id'    => $user->id,
            'name'  => $user->name,
            'email' => $user->email,
            'keys'  => $user->keys,
        ];
    }

    public function addKey($name, $key)
    {
        return $this->userModel->keys()->create([
            'name' => $name,
            'key'  => $key
        ]);
    }
}

我看过一些例子，通过创建存储库类进一步重构。 像UserController输入数据，将其发送到UserCreatorService ，后者获取UserRepository ，后者又获取UserModel 。 这似乎UserCreatorService是重复UserRepository ？

Answer 1

从 DDD（域驱动设计）来看，存储库的职责是负责加载、存储、修改和删除指定数据存储（可能是也可能不是数据库——它甚至可能是远程服务器或只是一个文件）。

另一方面，服务具有（或应该具有）执行某些有用活动的非常狭窄的职责。 每个服务单独实例化，然后注入到应用层或以上的代码中，起到桥梁的作用（桥接模式）。 这种方法已被证明是非常有利的，因为它允许管理其他不相关（解耦）代码之间的依赖关系。

这两个定义和概念的起源表明它们实际上是非常不同的东西。 您很偶然地注意到存储库和服务有明显的重叠，但这是由于实现细节或简单的误用所致。 在某些情况下，他们的职责可能齐头并进（导致合作），但他们确实是正交的概念。

此外，存储库应该来自深层（持久性或 DAL，数据访问层）。 另一方面，服务通常是垂直交叉的或出现在应用程序层。

通过适当的分层，存储库和服务之间的差异变得更加明显。

不要将它们视为可以随意移动的纯代码工件。 它们是定义明确的概念，有助于理解和设计系统的结构。 它们仅作为该设计的结果才进入实际代码。

我希望我能成功地写出一些清除一些想法并且不会混淆的东西。

Answer 2

您的问题没有明确的答案，因为您使用的模式在很大程度上取决于项目的复杂性和需求。

但是，服务和存储库是两种不同的东西。 Repository 是模型的通用包装器，也是您将查询写入数据库的地方。 IMO 你不应该在这里添加逻辑，存储库的唯一目的是将操作系统存储数据抓取到数据库中。 Repositories 的优点是“容易”切换到其他数据库系统。

服务，IMO，是您添加所有应用程序逻辑的地方。

有关其他信息，请参阅此答案。

Answer 3

我的项目经理说：

使用普通 PHP 的存储库模式。

使用 Laravel 项目的服务模式。

我不知道确切的原因。 但他有很多知识和经验。