个人对ssm开发的一点感悟

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