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

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

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

但是,服务和存储库是两回事.存储库是模型的常见包装器,是将查询写入数据库的位置.IMO你不应该在这里添加逻辑,存储库的唯一目的是将os存储数据存入数据库.存储库的优点是可以"轻松"切换到其他数据库系统.

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

有关其他信息,请参阅此答案.

Answer 2

从DDD(域驱动设计),存储库的职责是负责在指定的数据存储(可能是也可能不是数据库)上加载,存储,修改和删除实体 - 它甚至可能是远程服务器或只是一个文件).

另一方面,服务具有(或应该)执行某些有用活动的非常狭窄的责任.每个服务都单独实例化,然后注入应用程序层或更高层的代码中,这些代码充当桥接器(桥接模式).这种方法已被证明是非常有利的,因为它允许管理其他不相关(非耦合)代码之间的依赖关系.

这两个定义和概念的起源表明它们实际上是非常不同的东西.通过纯粹的机会,您注意到存储库和服务有明显的重叠,但这是由于实现细节或明显的误用.他们的责任可能在情况下齐头并进(引起合作),但他们确实是正交的概念.

此外,存储库应来自深层(持久性或DAL,数据访问层).另一方面,服务通常是垂直交叉切割或出现在应用层上.

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

不要将它们视为可以移动的纯代码工件.它们是明确定义的概念,有助于理解和设计系统的结构.它们仅仅因为该设计而拒绝实际代码.

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