通常，我将逻辑放在服务类中，而不使用存储库，例如，如下所示：
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，UserCreatorService获得UserRepository，UserRepository又获得UserModel。看起来UserCreatorService是UserRepository的重复？
3条答案
按热度按时间mklgxw1f1#
由于您使用的模式高度依赖于项目的复杂性和需求，因此您的问题没有“确定”的答案。
然而，服务和存储库是两个不同的东西。存储库是模型的一个通用 Package 器，是你向数据库写入查询的地方。我不应该在这里添加逻辑，存储库的唯一目的是获取操作系统存储的数据到数据库中。存储库的优点是“容易”切换到其他数据库系统。
服务IMO是添加所有应用程序逻辑的地方。
有关更多信息，请参阅this answer。
gwbalxhn2#
在DDD（域驱动设计）中，存储库的职责是负责加载、存储、修改和删除指定数据存储器（可能是也可能不是数据库--甚至可能是远程服务器或只是一个文件）上的实体。
另一方面，服务只负责（或应该负责）执行一些有用的活动。每个服务都是单独示例化的，然后注入到应用层或更高层的代码中，这就像一个桥梁（桥模式）。这种方法已经被证明是非常有利的，因为它允许管理其他不相关（非耦合）代码之间的依赖关系。
这两个定义和概念的起源表明，它们实际上是非常不同的东西。纯粹是偶然的机会，你注意到存储库和服务有明显的重叠，但这是由于实现细节或简单的误用。它们的职责可能在某些情况下齐头并进（导致协作），但它们实际上是正交的概念。
此外，存储库应该产生于更深的层次（持久层或DAL，数据访问层），而服务则通常是垂直的交叉层或产生于应用层。
通过适当的分层，存储库和服务之间的差异变得更加明显。
不要把它们看作是可以随意移动的纯代码工件。它们是定义良好的概念，有助于理解和设计系统的结构。只有在设计的结果下，它们才会变成实际的代码。
我希望我成功地写了一些东西，澄清了一些想法，而不是混乱。
hpxqektj3#
我的项目经理说：
我们对普通PHP使用存储库模式。
存储库模式是用来和数据库对话的，所以我们需要存储库模式来处理大规模的Laravel项目。
例如，如果你决定将你的数据库从Mysql改为CockroachDB，Laravel Eloquent不支持它，所以你必须更改整个项目中所有与Eloquent相关的php代码.但是有了Repository模式，你就不需要这样做了.因为你需要将你的仓库连接到Eloquent直接到数据库，如果你想迁移到CockroachDB，你只需要在一个地方修改代码，而不需要在应用程序的其他部分修改任何一行代码。
Laravel的服务可用于：
1 -短接控制器
2 -具有依赖性的可重用代码
3 -有些人使用服务只是为了curl请求外部API。
你喜欢怎么用它就看你了。