Laravel 单行为控制器设计的魅力

昨天，Jeffrey Way 发布了一条推文，他问大家更愿意将其控制器命名为单数还是复数。 我回答我两种方案都不选，我使用单动作控制器。随后发生的是，有的人同意，有的不同意，有的甚至做出了最奇怪的事情。

由于十分强烈的反映，我想写一篇文章来解释为什么我爱单行为控制器、还有我为什么觉得它们很美妙。

首先在开始文章之前，我想要说这个东西并不是只有单一的真相。与往常一样，我想指出的是，一切都归结于你的个人喜好。我只能教、建议和指出一些事情，由你来决定是否同意、不同意、接受、学习和 / 或调整。或者都不是。从这篇博客中获得你想要的，随心所欲地做让自己感到舒适的事情吧。

对比 CRUD 和 Domain Modelling

开始前，我们先来想想我们倾向于写 resourceful 的 CRUD 控制器。我相信很多人会坚持使用这种做法，因为这是 Laravel 中的一个标准做法，文档中的大多数示例也是使用这种方法。另外，这或许也是你在各类博客或 app 代码中经常看到的。

但是，如果你停下来思考一下，这是编写它们的最佳方法吗？是软件行业的一般性做法吗？最近几年，我在 “领域驱动设计”(Domain Driven Design) 等领域投入了大量时间，并且思考软件如何应用于你工作的领域（Domian）以及它转化的过程。当您开始考虑模仿您领域中无处不在的语言的术语和措辞时，您会发现您的代码将变得更加清晰明了，更加戳到点子上。（最后这一句话仍值得斟酌、改进）

最后，我相信编写软件的本质是尽可能地应用 domain processes 来让你的代码更加易读和更加可维护。

Resourceful 控制器在这两个方面做得并不好。首先，它们不易读，因为您倾向于根据数据来构建它们，而不是根据领域来构建它们。这样的话，你就会丢失上下文对照。你表现了数据的处理方式，但却没有说明到底发生什么了，也没有说明你使用哪个过程进行处理。

第二，你没有针对可维护性进行优化。由于你是根据数据结构来构建的，因此你也会跟着耦合进去。实际上，您的领域模型在不断发展，数据结构也在不断发展。如果你的数据结构处理着多个过程或领域的多个部分，那你将很难进行调整。

一个实际的例子

因为理论很无聊，上代码更加容易解释，所以我们来看一个实际的例子。

假设您正在构建一个应用，它允许用户去组织事件。您想提供一种创建，更新和删除这些事件的方法。这是一种非常典型的例子，你会用 CRUD 的方式来考虑实现它。那么，让我们看看就这样一个 resour