thinkphp框架使用心得

时间:2023-12-31 13:45:50

接触的第一个PHP框架就是TP,在使用的了一段时间后就放弃了,说实话TP的弊端挺多,之后又接触laravel框架,慢慢的就爱上laravel这个框架了。这段时间由于公司的原因,又不得不使用thinkphp框架,在这里分享下使用心得。

TP框架这一块,框架的耦合度高,整体代码半面对对象半过程化,整体使用起来不够方便,语义化很差;TP的默认路由还算不错;MVC这一块,控制器和应用请求、视图耦合度很高,几乎没有对请求进行封装,视图模板不支持深层次的继承,模板标签太多不够简洁(虽然每个标签都有最适合的应用场景),模型这块没有独立的查询构建器,而这一部分的职责基本由Model和DB类共同承担了,关联模型这块没有提供很好的预载入功能,存在N+1的问题;TP没有提供丰富的服务层代码,也没有明显的服务层概念,控制器之间的功能共享除了继承没有更好的方式;TP对于错误处理是通过返回值一层一层迭代的,而不是使用异常,程序越复杂,职责约分离迭代次数就越多

表单验证心得:

TP没有提供请求层的封装,请求通过路由直接进入控制器,并且TP的验证服务也是直接硬编码到Model里面,并通过create方法触发,create方法会完成数据字段的过滤,别名处理,验证处理,和自动填充等,由于实际情况中很多时候我们的表比较复杂,表中很多字段并不需要客户端的数据提交,例如:创建时间、状态、操作用户等等,那么只使用create方法做过滤是不够的,这个时候这个任务就会交给控制器去做,控制器中的每个方法对应前端用的一个用户请求,秉着客户端的提交都是危险的,那么在这里我们需要对提交的参数进行筛选。

总结:控制器中做提交参数的筛选,然后由模型来做数据验证

在laravel中有独立的请求层,并且验证是独立的服务。

客户端请求通过路由进入控制器,在进入控制器之前,laravel会通过参数的类型约束,利用反射技术来获取当前请求的实例,并根据请求定义的验证规则,调用验证服务,如果验证不通过则报一个系统异常,laravel会捕获这个异常并作出相应的处理,也就是说如果用户请求不符合规定,这请求都无法进入控制器

在这里并不是拿thinkphp和laravel做对比,因为他两压根就没有可比性,在这里只是说说别人的设计思路,这个真的很好