关于域的的一些遐想(一)

场景

有一个店铺列表查询,查询条件是店铺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就好了,可是这样均摊优惠券接口势必会和查询优惠券接口耦合,若是均摊优惠券须要一个新的信息的话,那么查询优惠券接口返回值就须要修改,而且因为商品信息都是入参传入的,因此入参也须要增长一些在这个逻辑中没必要要的参数)