Php 什么是存储库、服务和操作/控制器？

我使用有限的应用程序架构知识，使用Slim3和PHP启动了一个项目。计划是创建项目和单独的应用程序关注点。一切进展顺利，但随着应用程序的增长，事情很快变得混乱起来

这样做的整个想法是为了使开发更容易。在某种程度上确实如此，但我发现有时要对数据流进行跟踪是很复杂的

我需要一些关于什么是存储库、服务和控制器/操作的建议。以及它们在系统中应该如何工作。我目前对它们的理解如下：

存储库

存储库用于服务层和模型层之间。例如，在

UserRepository

中，您将创建包含要从数据库读取/写入的代码的方法。在PHP中，在repo方法中使用PDO或ORM。例如：

class UserRepository
{
    public function findByID($id) { ... }
    public function findByEmail($email) { ... }
    public function findByMobile($mobile) { ... }
    public function createEmail($email, $firstname, $lastname, $password) { ... }
    public function createMobile($mobile, $firstname, $lastname, $password) { ... }
}

我在这里放了一些示例方法。但可能还有更多

服务

服务层封装应用程序逻辑。例如，

UserService

将负责创建一个帐户，并执行所需的逻辑以注册用户。服务也可以是第三方，例如为Facebook的SDK或ORM创建服务

示例服务：

class UserService
{
    public function createMobile($mobile, $firstname, $lastname, $password)     {
    /*
     * Call a validation service to validate input
     */
    ...

    /*
     * Use UserRepository's findByMobile() to check if account exists
     */
    ...

    /*
     * Use UserRepository's createMobile() to create account
     */
    ...

    /*
     * Call SMS service to send verification code
     */
    ...
    }

    public function createEmail(...) { ... }
    public function getFollowers (...) { ... }
}

行动

我不确定这是否是一个真正的术语。它在Slim框架文档中使用，似乎代表了一个瘦控制器

操作包含很少的逻辑，用于调用服务。除非有正当理由，否则该操作很少直接调用存储库。该操作将对服务返回的数据执行基本检查，以便将响应发送回客户端

它们与单独的路线相连。我是这样使用它们的：

class ActivateEmailAction extends Action {

    public function __invoke(Request $request, Response $response, $args = [])
    {
        if(!$this->ci->ActivationService->activateEmail($args['token'])){
            return $response->withJson([
                'status' => 'error',
                'data' => null,
                'message' => 'Invalid verification token'
            ]);
        };

        return $response->withJson([
            'status' => 'success',
            'data' => null,
            'message' => null
        ]);
    }
}

我是否正确使用了这些模式？我采用的流程似乎是这样的：

一切从路线开始。例如，向

/create

发出请求。路由已注册到操作

行动决定调用什么服务

服务执行逻辑，必要时调用其他服务和存储库

服务将数据交还给操作

操作返回一个响应

---

任何建议都将不胜感激。

如果您对应用程序体系结构的了解有限，我建议您先阅读这本关于设计模式的书：

第二点是不要使用slim框架。这是一个小框架，供那些已经知道自己想要构建什么以及如何构建的人使用。绝对不是学习任何模式或应用程序架构的框架

我建议看一下Yii 2：

Yii使用大多数设计模式和体系结构解决方案，这些模式和解决方案在当今的大型应用程序中普遍使用，并且易于学习和理解

我是否正确使用了这些模式

是的，你是。我给出的一般建议是，不要给你的班级，特别是服务部门太多的责任：遵循单一责任原则，基本上说“我的班级应该只有一个改变的理由”（这是M.Fowler，据我记忆所及，实际上是，多亏了Gordon在评论中的更正）

---

您的

UserService

似乎正在处理太多不同的任务：它处理注册和获取追随者。可能会发短信。将与注册相关的逻辑提取到

UserRegistrationService

类中。

我发现投票结果过于宽泛。我不同意。使用这种设计模式设计应用程序通常只有一个正确答案。例如，您不会使用存储库使用来自的服务，这将是一种糟糕的做法。由于潜在的知识差距，我很可能会做一些被视为坏习惯的事情，这就是我为什么要问的原因。你做的一切都很好——这就是你想要的答案吗？）@GeorgyIvanov由于我的知识有限，且大部分基于猜测或常识，我认为在某个方面我做得不正确，因为我在管理项目时仍面临一些复杂性。Slim是学习模式的优秀框架，因为它迫使您实际创建应用程序的体系结构。Yii是建筑最佳实践的禁忌。为什么不呢？正如我所说，这些都是建议。对我来说，在一个大的框架内查看模式更容易理解，因为您可以看到它们是如何在生产中使用的，而不是在纸上使用的。理论而非实践是没有多大帮助的。啊，关于SRP的很好的建议。当我决定“这件事最好去哪里”时，我经常陷入困境。结果，我的课程做得太多了。通常，当您遵循SRP时，这会显著增加应用程序中的类数吗？@BugHunterUK，是的，但这不正是您要做的吗？将“大神”课程分为“小神”课程。）至于“类太多”——只要代码是逻辑组织的，就不太可能遇到这样的问题。