Laravel 跨越 CRUD
不想再写CRUD了
1
01. 面向领域的Laravel
人类是按类别思考的,我们的代码也应该反映出这一点。 首先,我并没有提出 领域 这个术语——我是从流行的编程范例 DDD,或 领域驱动设计 中得到的。根据牛津词典,领域 可以描述为“一个特定的活动或知识领域”。 虽然我对“域”一词的使用与 DDD 中使用时的含义并不完全相同,但有几个相似之处。如果你熟悉 DDD,你会在本书中发现这些相似之处。我尽力在相关的时候提到任何重叠和差异。 所以,域,你也可
2
02. 处理数据
在每个项目的核心,你都可以找到数据。几乎每个应用程序的任务都可以这样概括:以业务所需的任何方式提供,解释和处理数据。 可能你自己也注意到了这一点:在项目开始时,你不会一开始就构建控制器和处理逻辑,而是从构建 Laravel 所谓的模型开始。大型项目受益于制作关系模型和其他类型的图来概念化应用程序将处理哪些数据。只有明确了这一点,你才能开始构建适用于数据的入口点和钩子。 在本章中,我们将仔细研究如何
3
03. 行动
就像我们不想使用充满数据的随机数组一样,我们也不想项目中最关键的部分——业务功能——分散在随机函数和类中。在本章中,我们将研究另一种将此行为添加到代码库中的方法。我们将把这些用户故事作为项目的一级公民来对待,而不是在模型或控制器中混合功能。我倾向于称这些为“行动”。
4
04. 模型
在前面的章节中,我已经讨论了每个应用程序的三个核心构建块中的两个:DTO 和行动—即数据和功能。在本章中,我们将看一下我认为是这个核心部分的最后一部分:公开数据存储中持久化的数据;也就是说:模型。 现在,模型是一个棘手的主题。 Laravel 通过其 Eloquent 模型类提供了许多功能,这意味着它们不仅代表数据存储中的数据,它们还允许你构建查询,加载和保存数据,它们还具有内置的事件系统等等。
7
07. 进入应用程序层
最重要的是,你开始以相关业务概念的组为单位进行思考,而不是以具有相同技术属性的代码组为基础进行思考。