php - MVC(Laravel)在哪里添加逻辑

Question

假设每当我执行 CRUD 操作或以特定方式修改关系时，我还想做其他事情。例如，每当有人发布帖子时，我也想将某些内容保存到表中以进行分析。也许不是最好的例子，但总的来说，有很多这种“分组”功能。

通常我会看到这种类型的逻辑放入 Controller 中。在您想在很多地方重现此功能之前，这一切都很好。当您开始进入部分、创建 API 并生成虚拟内容时，保持事物干燥就成为一个问题。

我见过的管理方法是事件、存储库、库和添加到模型。以下是我对每一个的理解:

服务:这是大多数人可能会放置此代码的地方。我对服务的主要问题是，有时很难在其中找到特定的功能，而且我觉得当人们专注于使用 Eloquent 时，它们会被遗忘。我怎么知道我需要调用一个方法 publishPost()在图书馆我可以做的时候 $post->is_published = 1 ?

我认为这种方法运行良好的唯一条件是，您是否只使用服务(理想情况下， Controller 无法以某种方式访问​​ Eloquent)。

最终，如果您的请求通常遵循您的模型结构，这似乎只会创建一堆额外的不必要的文件。

存储库:据我了解，这基本上就像一个服务，但有一个接口(interface)，因此您可以在我不需要的 ORM 之间切换。

事件:我认为这是某种意义上最优雅的系统，因为你知道你的模型事件总是会在 Eloquent 方法上被调用，所以你可以像往常一样编写 Controller 。我可以看到这些变得困惑，如果有人有使用事件进行关键耦合的大型项目的示例，我希望看到它。

型号:传统上，我有执行 CRUD 并处理关键耦合的类。这实际上使事情变得简单，因为您知道 CRUD 的所有功能以及必须使用它完成的任何操作。

简单，但在 MVC 架构中，这通常不是我所看到的。从某种意义上说，我更喜欢这个而不是服务，因为它更容易找到，而且要跟踪的文件更少。不过，它可能会变得有点困惑。我想听听这种方法的缺点以及为什么大多数人似乎不这样做。

每种方法的优点/缺点是什么？我错过了什么吗？

Answer 1

我认为只要您遵循 SOLID，您提出的所有模式/架构都非常有用。原则。

对于在哪里添加逻辑，我认为引用 Single Responsibility Principle 很重要。 .另外，我的回答认为您正在从事中/大型项目。如果它是一个在页面上扔东西的项目，请忘记这个答案并将其全部添加到 Controller 或模型中。

简短的回答是:对您有意义的地方(提供服务) .

长答案:

Controller : 控制者的责任是什么？当然，您可以将所有逻辑放在 Controller 中，但这是 Controller 的责任吗？我不这么认为。

对我来说， Controller 必须接收请求并返回数据，这不是放置验证、调用数据库方法等的地方。

型号 :这是一个添加逻辑的好地方，比如在用户注册或更新帖子的投票计数时发送欢迎电子邮件？如果您需要从代码中的另一个地方发送相同的电子邮件怎么办？您是否创建了静态方法？如果该电子邮件需要来自其他模型的信息怎么办？

我认为模型应该代表一个实体。在 Laravel 中，我只使用模型类来添加诸如 fillable 之类的东西。 , guarded , table和关系(这是因为我使用了存储库模式，否则模型也会有 save 、 update 、 find 等方法)。

存储库(存储库模式) : 一开始我很困惑。而且，和你一样，我想“好吧，我使用 MySQL，仅此而已。”。

但是，我已经平衡了使用存储库模式的利弊，现在我使用它。我想现在，此时此刻，我只需要使用 MySQL。但是，如果三年后我需要改用 MongoDB 之类的东西，那么大部分工作就完成了。所有这些都以增加一个接口(interface)和一个 $app->bind(«interface», «repository») 为代价.

事件 ( Observer Pattern ): 事件对于可以在任何给定时间在任何类中抛出的事物很有用。例如，考虑向用户发送通知。
当您需要时，您可以触发事件以在您的应用程序的任何类中发送通知。然后，你可以有一个类似 UserNotificationEvents 的类。处理用户通知的所有触发事件。

服务 :到目前为止，您可以选择向 Controller 或模型添加逻辑。 对我来说，在服务中添加逻辑很有意义 .让我们面对现实吧，服务是类的一个奇特名称。并且您可以在您的应用程序中拥有尽可能多的类。

举个例子:不久前，我开发了类似谷歌表单的东西。我从 CustomFormService 开始最后得到 CustomFormService , CustomFormRender , CustomFieldService , CustomFieldRender , CustomAnswerService和 CustomAnswerRender .为什么？因为这对我来说很有意义。如果你和一个团队一起工作，你应该把你的逻辑放在对团队有意义的地方。

使用服务与 Controller /模型的优势在于您不受单个 Controller 或单个模型的约束。您可以根据应用程序的设计和需求，根据需要创建任意数量的服务。再加上在应用程序的任何类中调用服务的优势。

这很长，但我想向您展示我是如何构建我的应用程序的:

app/
    controllers/
    MyCompany/
        Composers/
        Exceptions/
        Models/
        Observers/
        Sanitizers/
        ServiceProviders/
        Services/
        Validators/
    views
    (...)

我将每个文件夹用于特定功能。例如 Validators目录包含 BaseValidator负责处理验证的类，基于 $rules和 $messages特定验证器(通常每个模型一个)。我可以很容易地将此​​代码放在一个服务中，但对我来说有一个特定的文件夹是有意义的，即使它只在服务中使用(现在)。

我建议您阅读以下文章，因为它们可能对您解释得更好一些:

Breaking the Mold by Dayle Rees (CodeBright 的作者):这就是我把所有东西放在一起的地方，尽管我改变了一些东西来满足我的需要。

Decoupling your code in Laravel using Repositories and Services作者:Chris Goosey:这篇文章很好地解释了什么是服务和存储库模式以及它们如何组合在一起。

Laracasts 也有 Repositories Simplified和 Single Responsibility这是带有实际示例的好资源(即使您必须付费)。