个人对ssm开发的一点感悟
问题:由于在ssm开发过程中不是很清楚一些代码到底放在控制层,还是业务层,很纠结。下面说说自己的想法
1.对于控制层:
处理请求参数:对客户端发过来的参数进行校验防止以空指针异常,防止数据库进行一些没必要的查询;参数但是对于一些引用类型,它里面的属性如果再有引用类型,我们可以先把参数的属性先拿出来,在控制层做好校验,校可以把的参数交给业务层,这样我们所有的校验都放在了控制层,以后想找校验代码直接看控制层就行。
对于一个请求想查多个结果的,我们可以在控制层分开调用业务层进行,查询而不要把请求一下子都交给业务层,一个业务太复杂也不利于我们后期的维护,我们可以将这多个查询都在业务层谢好玩,控制层直接调用,这样的话让我们业务层功能分开的粒度更大,有助于以后某个页面只只要要其中一个查询结果时,我们直接调用现有业务就行,而不用再写业务。
对于页面没有给你参数,其实是要参数的,比如查询今天的游客数,你可以在控制层将今天这个参数做好传给业务层,而不要让业务层做。
处理返回结果:对业务层返回的结果,如果不是页面直接需要的结果,我们可以在控制层把返回结果处理成页面需要的类型,然后返回给页面。
2对于业务层:
处理请求参:数不用关心参数是否不行,因为控制层已经校验好,而应该关心的是直接根据这个参数,我们是否能拿到页面需要的结果,如果不行,该对参数进行处理的,此时进行处理,如控制层发过来的是月份号叫你,查这个月之前的会员总数,你可进行尾加上31 变成本月的最后一天处理变成这个月最后一天,然后交给dao进行查询,不要把不成熟的条件交给dao,让dao自己加条件,这样我们以后想看最终条件调见我时,直接在业务层看就ok。
处理返回结果:如果你拿到的查询结果不是控制层需要的,那么你就处理成控制层需要的结果然后返回。
总结一下:控制层校验参数,把业务层返回的结果处理成页面需要的。业务层处理参数,把控制层给的参数转成查询时用到的最终参数,把结果处理成控制层需要的。尽量不要在一个业务中调用多个dao,可以把调用多个dao写成对个独立的业务,让控制层来调。
觉得这个想法不错,想分享一下。