江苏龙网

  1. 首页 > 人文 > >

程序员小助手|3分钟短文：无私分享！Laravel模型使用2个小技巧

引言
上一节我们详细讲解了模型的访问器功能 ， 可以轻易扩展模型的属性访问 ， 灵活又标准地增强了模型的读取数据的能力 。
程序员小助手|3分钟短文：无私分享！Laravel模型使用2个小技巧
文章图片
本文我们接着往下讲 ， 说说模型的修改器 ， 以及模型的职责 。
修改器
有没有这样一种用法：使用表单获取一个字段的输入 ， 使用加密算法 ， 或者摘要方式对字段处理后存入数据库 ， 这在数据库密码字段是常用的处理手段 。
如果写操作在程序内到处都是 ， 零散地分布在业务代码的各个地方 ， 我们总不至于每次都要写一次相同的代码吧？相同的业务逻辑 ， 提取出来 ， 抽象出来 ， 只写一次 ， 这才是高效代码的王道 。
laravel这个注重设计模式的现代化框架 ， 自然是不会做无用功 。 于是对应读取器 ， 就有了修改器 ， 专门用于写入数据库时起作用 。 比如对于写操作 ， 某个字段的值写入 ， 默认使用bcrypt方法加密之后存入数据库 。
classUserextendsModel{publicfunctionsetPasswordAttribute($password){$this->attributes['password']=bcrypt($password);}}
上述方法调用模型的$attributes属性 ， 并使用自定义方法改写 ， 在使用->password属性进行赋值后 ， 就会调用该方法的代码并执行 。
我们仍然在tinker内进行演示：
$user=newUser;$user->password='blah';echo$user->password;//输出$2y$10$e3ufaNvBFWM/SeFc4ZyAhe8u5UR/K0ZUc5IjCPUvOYv6IVuk7Be7q
自定义方法
框架独立出来模型这个数据库操作层的目的 ， 就是为了把数据操作全部集中到模型内完成 ， 以便可以全局统一 ， 规范地编写代码 。
下面举个例子 ， 说明一下哪些逻辑应该放在模型层操作 。 比如有一个视图文件内的一个展示片段：
@if($event->started_at->isToday())Thiseventisoccurringtoday!@endif
其中$event是模型Event对象的一个实例 ， start_at方法是模型的一个属性 ， 也是数据库表的一个字段 。 按照之前章节的介绍 ， 我们对其使用了访问器的方法 ， 自动在读取的时候使用Carbon类返回一个实例化对象 。 所以上面的代码片段可以使用isToday()这个Carbon类的方法 。
但是在模型层面进行类库方法的调用 ， 有些单独 ， 且零散 。 假如有些API接口要使用此方法格式化 ， 或者别的页面也要重用这个方法 ， 显然放在模型内更为合适 。
考虑在模型内添加以下代码：
classEventextendsModel{publicfunctionoccurringToday(){return$this->started_at->isToday();}}
声明一个public的公开访问的私有化方法 ， 并操作对象的实例$this的属性和方法 。
那么上述的blade模板内的代码就可以更换如下：
@if($event->occurringToday())Thiseventisoccurringtoday!@endif
这样逻辑摘出来就清楚的多了 。 而且可维护性更强 。 为什么？因为假如后期我们业务出现变动 ， 不再使用start_at字段进行判断 ， 可以很容易地通过修改occurringToday方法而达成全局生效的目的 。
这样的程序就很灵活了 。
写在最后
本文描述了laravel模型内很常用的两个小技巧 。
一个是修改器 ， 让你不必每次在写入数据的时候 ， 考虑如何转换 ， 如何判断 ， 不再写重复的啰嗦的代码；
一个是如何优化视图文件 ， 以及如何权衡设计技巧 ， 让模型做模型应该做的事情 ， 尽量在代码内把职责划分清楚 。
规范的设计 ， 能让一个项目的代码更为健壮 。
Happycoding:-)
【程序员小助手|3分钟短文：无私分享！Laravel模型使用2个小技巧】我是@程序员小助手 ， 专注编程知识 ， 圈子动态的IT领域原创作者


    推荐阅读


    上一篇：芭乐科技社|其实是你不会用，手机“飞行模式”为何还不取消？内行人说出实情

    下一篇：ZAKER生活|一路警车护送到医院抢救，幼儿生病昏迷家长求助交警