關於域的的一些遐想(一)

場景

有一個店鋪列表查詢,查詢條件是店鋪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就好了,可是這樣均攤優惠券接口勢必會和查詢優惠券接口耦合,若是均攤優惠券須要一個新的信息的話,那麼查詢優惠券接口返回值就須要修改,而且因爲商品信息都是入參傳入的,因此入參也須要增長一些在這個邏輯中沒必要要的參數)