工程之殇

今天晚上的心路历程好让人泄气。

继续揣摩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,这就是工程之殇。

于是,我只能啥都不改,悻悻地上床睡觉。又是一个胡思乱想晚上。

博客园精华区稿源:博客园精华区 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合编程 » 工程之殇

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录