【问题标题】:Models, Repositories, Service classes & Jobs (commands) [closed]模型、存储库、服务类和作业(命令)[关闭]
【发布时间】:2016-01-03 19:16:06
【问题描述】:

我需要一些帮助来了解每个在大型应用程序中的作用。我先从一个场景开始:

  • 像往常一样会有用户
  • 用户必须具有 MembershipType(免费、基本、商业)。
  • 用户可以拥有(非必需)一个企业(用户拥有一个或零个企业)
  • 用户可以有一个订阅(用户有一个或零个订阅)。
  • 订阅需要与 MembershipType 相关的 SubscriptionPlan。因此,“基本”会员类型在 Stripe 中将具有“基本 2015”计划;一个“企业”将有一个“企业 2015”计划。
  • 一个用户有地址(用户多对多地址)
  • 基本用户必须有“个人”地址存档,而企业用户必须有“公司”地址存档
  • 还有其他要求,但这足以获得更好的画面

到目前为止,我有这些模型:用户、会员类型、业务、订阅、订阅计划和地址。

一些业务逻辑要求我至少有以下方法: - 用户 isBusiness() - 用户 hasAddress(type) 其中类型是(个人或企业) - 会员类型 getPlanForCurrentYear()
- 需要其他东西,但我会在这里停下来

现在举个例子:John 注册并需要提供基本信息(电子邮件、密码、姓名)。他注册为企业。在这个基本的注册过程之后,他会登录并通知他需要在获得访问权限之前完成他们的个人资料。然后要求他提供商业信息(姓名、网站、电子邮件、电话)。我还需要营业地址。然后他必须订阅当前年度计划“business2015”。

所有这些我都设法做到了,但我是在我的控制器中做到的。正如其他帖子中的一些建议,首先使其工作,然后决定是否需要将其提取到存储库。好吧,我已经到了确定我需要使用存储库的地步,因为它变得越来越复杂,我必须不断地修改我的控制器。因此,经过大量研究后,我仍然对如何让我的 DB 到 UI 的双向工作没有混乱。

我的研究使我意识到我需要使用存储库,也许是服务类和作业。有人可以分享一些关于我需要什么才能拥有一个好的架构的想法吗?

  1. 每个模型都需要一个存储库吗?拥有一个带有通用方法(all、getId、create、update、delete 等)的接口和抽象存储库。如果是这样,我将如何在它们之间关联存储库?

  2. 我是否需要在特定时间编排所有涉及的存储库的服务类(如 RegisterUser、CompleteProfile)?

  3. 在这种情况下我应该如何使用作业?从控制器调度它们并注入存储库或服务类?

  4. 在 Laravel(开源)中是否有大型应用程序的示例,我可以看一下以了解所涉及的一些原则?

谢谢。

【问题讨论】:

  • 投票结束。您的问题基本上是在询问如何构建整个应用程序。它远非广泛。 Laracasts.com 有很好的教程,介绍如何使用服务、控制器、命令、存储库等。
  • @Gravy 我尽力解释。是不是太宽泛了?嗯,就看你怎么想了。我不需要把整个架构从这里弄出来,而是一个开始。一开始什么都没有。我想从比我更有经验的人那里得到一些东西。一个简单的答案可以帮助我转移注意力并专注于需要的东西。

标签: php laravel repository-pattern domain-service-class


【解决方案1】:

1 & 2. 目前,您正在通过控制器中的模型查询数据库。首先在控制器之外编写一个中间层。这可以称为服务层。所以让我们假设一个用户想要注册,然后 POST 到你的控制器的 store 方法。

创建一个UserService 并添加一个方法register。让您的服务与模型对话。并且您的控制器与服务对话。

UserController extends BaseController {

    // Dependency injected the UserService
    public function __construct(UserService $userService) {
        $this->userService = $userService;
    }
    public function store(){
        // validate input

        // register the user
        if (!$this->userService->register($input)) {
            // return error
        }
        // return success
    }
}

class UserService {
    protected $user;

    // Dependency injected the User model.
    public function __construct(User $user) {
         $this->user = $user;
    }

    public function register($input) {
         return $this->user->create($input);
    }
}

一旦掌握了这一点,您就可以考虑接口并抽象出更进一步的层。

暂时忘记接口——你可能还不需要它们。当您可以进一步换出实现时,接口非常好。例如现在您正在使用 Stripe Billing,但有一天您可能希望使用 Paypal,因此您将支付系统编程为一个接口,该接口基本上是一份合同,明确规定了需要公开的公共方法。

  1. 你还不需要工作。

  2. 根据我之前的评论,www.laracasts.com 是一个非常好的资源。

一旦你掌握了从控制器中抽象出细节的窍门,剩下的就应该自然而然地及时出现。

【讨论】:

  • 谢谢!您在这里谈论用户服务作为控制器和模型之间的缓冲区?这与存储库相同吗?我在 github 上找到了 Laravel.io 的源代码,乍一看他们做了这样的事情:控制器与服务对话,服务与存储库对话,存储库与模型对话,模型与数据库对话。像这样:UserController 输入数据,将其发送到 UserCreatorService,后者获取 UserRepository,而后者又获取 UserModel。我在正确的道路上吗?
  • 顺便说一句,我在 Laracasts 上并在存储库等上观看了很多视频,但我似乎无法获得更大的图景!
  • 服务层应该包含业务逻辑。因此,当您想要注册用户时,您可能需要: 存储在数据库中后通过电子邮件发送用户和其他操作。所以你可以把这个逻辑放在服务层。
猜你喜欢
  • 2010-10-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-01-14
  • 1970-01-01
  • 2017-09-19
  • 1970-01-01
相关资源
最近更新 更多