Laravel程序架构设计思路之使用动作类(2)

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

动作类的装饰

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

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

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

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

AppServiceProvider.php

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

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


AppServiceProvider.php

总结

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

使用单动作类的好处:

小巧而单一的逻辑域能够防止代码重复并提高代码的可重用性,保持稳定。

易于针对各种场景进行独立测试。

富有意义的命名在大型项目中更容易阅读。

易于装饰。

整个项目的一致性:防止代码分布在 Controllers、Models 等。

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

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

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对脚本之家的支持。

您可能感兴趣的文章:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/089b9471a3379d4dd6d24e64a82f01f4.html