数码控科技猎奇Iphone动漫星座游戏电竞lolcosplay王者荣耀攻略allcnewsBLOGNEWSBLOGASKBLOGBLOGZSK全部技术问答问答技术问答it问答代码软件新闻开发博客电脑/网络手机/数码笔记本电脑互联网操作系统软件硬件编程开发360产品资源分享电脑知识文档中心IT全部全部分类全部分类技术牛文全部分类教程最新网页制作cms教程平面设计媒体动画操作系统网站运营网络安全服务器教程数据库工具网络安全软件教学vbscript正则表达式javascript批处理更多»编程更新教程更新游戏更新allitnewsJava新闻网络医疗信息化安全创业站长电商科技访谈域名会议专栏创业动态融资创投创业学院 / 产品经理创业公司人物访谈营销开发数据库服务器系统虚拟化云计算嵌入式移动开发作业作业1常见软件all电脑网络手机数码生活游戏体育运动明星影音休闲爱好文化艺术社会民生教育科学医疗健康金融管理情感社交地区其他电脑互联网软件硬件编程开发360相关产品手机平板其他电子产品摄影器材360硬件通讯智能设备购物时尚生活常识美容塑身服装服饰出行旅游交通汽车购房置业家居装修美食烹饪单机电脑游戏网页游戏电视游戏桌游棋牌游戏手机游戏小游戏掌机游戏客户端游戏集体游戏其他游戏体育赛事篮球足球其他运动球类运动赛车健身运动运动用品影视娱乐人物音乐动漫摄影摄像收藏宠物幽默搞笑起名花鸟鱼虫茶艺彩票星座占卜书画美术舞蹈小说图书器乐声乐小品相声戏剧戏曲手工艺品历史话题时事政治就业职场军事国防节日风俗法律法规宗教礼仪礼节自然灾害360维权社会人物升学入学人文社科外语资格考试公务员留学出国家庭教育学习方法语文物理生物工程学农业数学化学健康知识心理健康孕育早教内科外科妇产科儿科皮肤科五官科男科整形中医药品传染科其他疾病医院两性肿瘤科创业投资企业管理财务税务银行股票金融理财基金债券保险贸易商务文书国民经济爱情婚姻家庭烦恼北京上海重庆天津黑龙江吉林辽宁河北内蒙古山西陕西宁夏甘肃青海新疆西藏四川贵州云南河南湖北湖南山东江苏浙江安徽江西福建广东广西海南香港澳门台湾海外地区

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

来源:脚本之家  责任编辑:小易  

前言

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

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

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

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

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

避免神类的坑

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

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

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

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

介绍单动作类

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

首先,让我们抛弃过于笼统和模糊的服务术语,来了解一下我们的新动作类,并定义它们是什么以及它们可以做什么。

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

创建我们的 CreateUser 动作类

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

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

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


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

动作类的嵌套

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


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

动作类的装饰

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

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

AppServiceProvider.php

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


AppServiceProvider.php

总结

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

使用单动作类的好处:

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

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

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

总结

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

您可能感兴趣的文章:


  • 本文相关:
  • 对于laravel 5.5核心架构的深入理解
  • laravel中使用自己编写类库的3种方法
  • laravel框架中扩展函数、扩展自定义类的方法
  • laravel 5.5 的自定义验证对象/类示例代码详解
  • laravel 加载第三方类库的方法
  • php实现javascript中的escape及unescape函数代码分享
  • php编译安装中遇到的两个错误和解决方法
  • php 接入微信扫码支付总结(总结篇)
  • md5 16位二进制与32位字符串相互转换示例
  • php实现数据分页显示的简单实例
  • joomla组件开发入门教程
  • php实现的百度搜索某地天气的小偷代码
  • php函数mkdir实现递归创建层级目录
  • php使用mb_check_encoding检查字符串在指定的编码里是否有效
  • zf框架的zend_cache缓存使用方法(zend框架)
  • 免责声明 - 关于我们 - 联系我们 - 广告联系 - 友情链接 - 帮助中心 - 频道导航
    Copyright © 2017 www.zgxue.com All Rights Reserved