Laravel 程序架构设计思路:使用动作类
119

file

当我们谈论到应用程序的架构的时候,经常会问到一个经典的问题,那就是“这段代码应该放在哪里比较好”。 因为 Laravel 是一个相当灵活的框架,所以要回答这个问题其实没那么容易。我应该把我的业务逻辑写在 Model 层,还是 Controller 层,或者是其他地方?

当你的应用程序仅有一个接入点,把业务逻辑写在 Controller 层是可以的。但是现在更普遍的的情形是,有很多接入点去调用相同的功能模块。

比如说,太多数的应用程序都有用户注册的功能,它的流程是调用一个控制器然后返回一个注册成功或者失败的视图。假如这个应用程序还有移动端,那就很可能要提供一套针对移动端用户注册的 API ,因为它需要返回的数据格式是 JSON 。而且利用 Laravel 的 artisan 命令来创建用户也很常见,尤其是在项目前期的开发阶段。

file

上面这两段代码可能看起来没有什么问题的,但是,随着业务逻辑的增加,就会显得代码很冗余。举个例子,如果你需要新用户注册完之后,增加给用户发送邮件通知的功能,你必须要再上面两个控制器中都添加发送邮件的代码。但是如果要保持代码的简洁优雅,我们可以把这些业务逻辑写到其他地方。

对于“把业务逻辑代码写到哪里”的这个问题,你去任何论坛都可以得到一个普遍的答案,那就是 “使用一个 service 层,然后在 controller 层调用这个服务类”。是的,没错,问题是我们应该怎么设计 service 类?是创建一个 UserService 类来实现所有跟用户用户有关的业务逻辑,然后把这个类注入到需要用到的 Controller 层?或者是还有其他方案?

避免神类的坑

首先,可以尝试为一个特定的模型创建一个单一类,其中包含所有的代码。例如:

file

看起来很完美:我们可以任何控制器中申明或者使用 create/delete 方法,并且得到我们想要的结果。但是,这种实现有什么问题呢? 那就是我们在解决问题的过程通常很少使用单一的模型 

比如说,当我们给一个用户创建了账号的时候,也要同时给用户单独创建一个 blog 。如果按照当前的方式去实现这个流程,我们就必须创建一个 BlogService 类,然后将其依赖注入到 UserService 类。

file

显而易见,随着应用程序的业务的增长,将会有几十到上百个 service 类,其中的一些 service 类需要依赖 5 到 6 个其他 service 类,最终的结果就是,出现代码的冗余跟混乱的局面,而这个局面是我们想不惜一切代价去避免的。

介绍单动作类

那么,如果不是用一个单一的服务类加上几个方法,我们决定把它分成几个类?下面是我最近每一个项目都采用的方法,结果很不错,推荐给大家。

首先,让我们抛弃过于笼统和模糊的术语 service(服务类),并且将我们新建的类命名为 actions(动作类),并定义它们是什么以及它们可以做什么。

  • 一个动作类,应该有一个能够说明其功能的名字,比如:CreateOrder, ConfirmCheckout, DeleteProduct, AddProductToCart等。
  • 它应该有且只有一个公共方法,作为 API 。理想的情况下,应该是相同的方法名,像 handle() 或者 execute() 。如果需要对我们的动作类实现某种适配器模式,这是非常方便的。
  • 它必须对请求和响应不可知。它不处理请求,也不发送响应。这样的职责应该由控制器来承担。
  • 它可以依赖其它的动作类。
  • 如果有任何事情阻止它执行和/或返回期望的值,那么它必须通过抛出一个 Exception 来强制执行相关的业务逻辑,并且让调用者(或者 Laravel 的 ExceptionHandler )来承担如何呈现/响应异常的责任。

创建我们的 CreateUser 动作类

现在,让我们看看前面的例子,并用一个单动作类来重构它,我们将命名为 CreateUser 。

file

你或许想知道当邮箱地址已经被占用时,该方法为什么会抛出了异常。 这难道不是请求验证来保证的吗?当然可以。然而,在动作类内部来执行业务逻辑不是更好吗?这样使得逻辑变得易于理解和调试。

让我们看看使用我们动作类之后的控制器代码,如下:

file

现在,无论我们做什么修改,用户注册过程都会由 API 和 Web 版本处理,优雅整洁。

动作类的嵌套

假如,我们需要一个动作类将 1000 个用户导入我们的应用中。我们可以写一个动作类,并且继续使用上文的 CreateUser 类:

file

非常整洁,不是吗?我们可以通过将其嵌入在 Collection::map() 方法中来重用 CreateUser 代码,然后返回所有新建用户的集合。当邮件被占用的时候,我们可以通过返回 Null Object 或者在 Log 文件中记录一下,你应该已经想到了。

动作类的装饰

现在,假设我们想在日志中记录每一个新注册的用户。我们可以将代码写在动作类内部,也可以使用装饰者模式。

file

然后,我们可以使用 Laravel 的 IoC 容器将 LogCreateUser 类绑定到 CreateUser 类,所有每当我们需要一个后者的实例时,前者都会注入进来:

file

AppServiceProvider.php

这使得使用配置或环境变量来控制日志记录功能的激活或停用更为方便:

file

AppServiceProvider.php

总结

使用这个方法似乎会需要很多的类。当然,用户注册仅仅是一个简单的例子,旨在保证代码的简短清晰。一旦项目的复杂度开始增长,动作类的真正的价值就越来越明显,因为你清晰的知道代码所在及其界定。

使用单动作类的好处:

  • 小巧而单一的逻辑域能够防止代码重复并提高代码的可重用性,保持稳定。
  • 易于针对各种场景进行独立测试。
  • 富有意义的命名在大型项目中更容易阅读。
  • 易于装饰。
  • 整个项目的一致性:防止代码分布在 Controllers、Models 等。

当然,这个方法是基于我过去几年使用 Laravel 的一些经验和我在一些项目中的实践。这对我真的很有用,现在我甚至在一些中小型项目中使用。

如果你有不同的方法,我非常期待读一读。


Practice makes perfect.

原文地址:https://medium.com/@remi_collin/keeping-...

译文地址:https://laravel-china.org/topics/12791/l...

本帖已被设为精华帖!
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 10

棒棒哒。。。

4个月前

是事件进行解耦是不是更好一些,如果数据不是要求强一致性的话

4个月前

方法后面加冒号是什么意思

4个月前

这篇文章点出了目前 MVC 结构的最大问题:缺 Service 层。
laravel 默认没建立 service 目录,说明 laravel 也不想解决这个问题。
文章提出了问题,然而,解决方案是错的。
service 层是要跟业务走的。而不跟着数据模型走的。
一个对外函数实现一个对外功能。 相同模块里的函数调用

我们给一个用户创建了账号的时候,也要同时给用户单独创建一个 blog 。

解决方案是在一开始 UserService 里引用 BlogLibService->createBlog()。
BlogService 和 BlogLibService 的区别,就是 LibService 只对内服务。Service 对外。
如果前期你觉得没必要折腾,也可以在 UserService 里直接引用 BlogModel 的几个方法。 如 create ,init 等。

CreateUser 动作类 这种只是加了复杂度。

如果你要事件,日志处理,不要忘记了 PHP 的万能的 __call() 方法。

Service 方法在写入动作的时候很方便,麻烦的是用于页面显示的粒度问题,要一个 Service 解决还是多个 Service ,这就看实践了。

4个月前
Summer

@dvaknheo 没有所谓对错之分,你的方案对于那些使用 observer 的人来讲,也是错的,对于喜欢 repository 模式的人来讲,也是错的,对于 event bus 的人来讲,也是错的,对于我这种越简单越好的直接使用 Model 的人来讲,也是错的....

只是不同的程序架构设计模式而已,自己用的趁手,项目里统一起来,团队里大家行为一致即可。

4个月前
webstar

apiato 就是这个思想

4个月前

@xuhui 返回值类型

4个月前

程序员应该多关注下数据结构和数据间的关系,少浪费些时间在研究代码和代码目录组织结构上,事实证明研究这种东西纯属浪费时间。

一个设计良好的数据和表结构,就是代码懒点也没关系,优秀的表设计和数据设计会让整个程序很稳健,重构你代码的继任者也会感谢你。

4个月前

不错,简单瞬间干脆很多

2个月前

控制器有没有必要将它写成动作类呢?

1个月前

  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!