场景

有一个店铺列表查询,查询条件是店铺Id/店铺名称(通过下拉框选择)。这个时候我们在和前端约定,往往是传一个queryType和queryValue,这个时候Service和Dao就有两个选择:

1. Service和Dao的查询参数QueryParam直接定义queryType和queryValue两个变量(或者直接和Controller共用一个参数),然后在生成SQL的时候把这两个字段解析成ShopId和ShopName.这样做的好处就是可以和Controller公用一个实体,避免了Controller层和Service之间的实体转换

2. Service自己定义一个查询实体QueryParam,并且在实体中直接定义ShopId和ShopName.如果仅仅站在Service的角度来思考这个问题的话,Service必须拥有自己的入参,所以在QueryParam里面定义ShopId和ShopName对接口的语义理解上来说是最合理

思考

这里有两种设计方式,一个自上至下,通过设计Controller然后考虑Service的入参和出参,另外一个是模块独立考虑,站在Service上考虑自身的接口应该怎么设计,避免了因为第一种设计方式,由于Controller的参数而直接影响了Service接口参数的设计(QueryParam定义ShopId和ShopName绝对比定义定义queryType和queryValue直观),并且最坏的情况就是Service和Controller公用一个参数,因为前端的传参是很容易变化,如此和前端的参数耦合,当前端传值名称变化以后Service就得跟着改

引申

在我们平常开发大型系统的时候,往往也会将系统进行有效的分层比如有Service,Dao,Facade...每个层之间都应该有自己的入参和出参,各个层之间的耦合度就更加小,入参和出参更加的干净,接口更加容易让人理解(在某一层次的内部之间还会有更小的分层,这些小的分层之间甚至在一个层次的接口与接口之间,也会涉及到这个问题).

结论

各个层次都需要有自己的域

1. 好处:通过在不同层次定义不同的域,不仅在代码的可读性上更加的友好并且不同层次之间或者同一层次之间的接口也更加的独立,耦合度更加小

2. 坏处:有太多的实体,并且不同层或者同层之间的实体需要相互装换.

      public interface CouponService{public List<Coupon> queryCoupon(GoodsParam1 goods);public List<CouponShareGoodsDTO> shareCouponAmount(CouponParam1 coupon);}public CouponGoodsResultDTO calculate(Param param1,List<GoodsDetail> goods){List<Coupon> coupons = CouponService.queryCoupon(GoodsParam1 goods);//选中优惠券coupon,coupon实体下面标明适用的商品Id-------①//通过coupon下的商品Id,从GoodsDetail中取相应的价格信息进行均摊-------②CouponService.shareCouponAmount(coupon);}

   如上代码是属于比较麻烦的一种类型,因为Coupon自己实体下直挂了那些这个优惠券适合的商品Id,并没有其它信息,所以下面在计算优惠券的时候又得从原始入参中将一些价格信息取出来(如果①中能把商品的价格信息全部返回的话,②中就直接get,set就行了,但是这样均摊优惠券接口势必会和查询优惠券接口耦合,如果均摊优惠券需要一个新的信息的话,那么查询优惠券接口返回值就需要修改,并且由于商品信息都是入参传入的,所以入参也需要增加一些在这个逻辑中不必要的参数)