工程之殇
2018-01-14 02:37 轩脉刃 阅读(669) 评论(1) 编辑 收藏 举报今天晚上的心路历程好让人泄气。
继续揣摩laravel项目中ValidationException的设计,看到里面的status,觉得好奇怪,为什么是叫status,不是直接把code设置一下呢?然后想想,好像也对,code是异常的代码,而status是http response的代码,两个不应该混为一谈。
接下来我想看下既然ValidationException没有设置code,那laravel中是怎么做到在渲染的时候把http response statuscode 设置为status的。然后就看到了render里面。
第一次看到这个代码,恶心坏了,这个分支的结构,真是太恶心了。然而琢磨了几个小时之后,直到写这篇文章的时候,我有种错觉,我已经把这坨shi吃下去了...
首先我想着是不是能优化下这个函数,是不是能把这里的渲染逻辑放到exception中呢?嗯,好像很完美。但是想想,不对啊。。。我定义一个异常的时候还需要定义好它的渲染方式,定义好它的json输出,html输出?明显不好。。。好,我只能接受在一个大类handler.php里面统一作处理。
其次我想,是不是可以再定义一个基类,让所有的类继承这个类。这里几个类最好的可能就是HttpResponse了。然后其他两个都继承这个类?然后在这个基类里面写一些逻辑?不对啊。。。不管你这个基类是什么,它还是一个异常,不应该在这个异常里面做这么复杂的事情啊。同上。而且,都继承这个类,子类里面也要有各种实现。。。不妥不妥。
好,那么我整理下handler类可好,封装一个函数,把所有的异常都进行遍历可好。但是这个方法可能就是二维的了,request是否json,和异常类型,两个纬度。那么,又是一个很恶心的函数。
呵呵,总而言之,好像没有最优美的解决方案了。遂放弃优化这块。
想想,这个明显是作者的设计不足。设计不够有扩展性。我又详细看了下laravel的异常,几个很大的问题:
1 异常继承随便继承,没有收口,以后要做统一处理,只能一个个遍历处理。有的继承Exception,有的继承Sysforny的Exception,有的继承Responseable接口。。。各种混乱。
2 输出格式没有统一。各种不同的异常需要不同的输出格式,再加上是否调试模式,这里已经有好几个分支了。没有考虑过统一的格式过滤。
哎,优雅的laravel内部还是很多问题的。这个地方,不是很优雅。但是,只能说,介于历史包袱,它只能做到这样了。
于是我想到我们平时的业务工程,不就是和这种项目一样么,越来越久之后,背上承重的壳,也就这么痛苦不堪了。so,这就是工程之殇。
于是,我只能啥都不改,悻悻地上床睡觉。又是一个胡思乱想晚上。
实时了解作者更多技术文章,技术心得,请关注微信公众号“轩脉刃的刀光剑影”
本文基于署名-非商业性使用 3.0许可协议发布,欢迎转载,演绎,但是必须保留本文的署名叶剑峰(包含链接http://www.cnblogs.com/yjf512/),且不得用于商业目的。如您有任何疑问或者授权方面的协商,请与我联系。