關於業務分層

業務分層思想

根據MVC分層思想，我們的項目都會分成3層，而業務層是在M裡面的。
現在的項目都會把M分層兩層即DAO層(持久層)和Service層(業務層)。
由於業務的發展,Service層裡面的業務會越來越複雜,這個時候為了保持Service層方法的抽象層次一致性,一般我們都會寫成堆成堆的private方法，舉個例子。

    public class OrderServiceImpl implements OrderService{        public void createOrder(){            checkActivity();            createOrderInfo();            createTrade();        }        private void createOrderInfo(){            createOrderInfo();            createSkuInfo();        }        private void createOrderInfo(){            //建立訂單資訊        }        private void createSkuInfo(){            //建立訂單對應單個SKU資訊        }        private void createTrade(){            //調用支付介面,建立支付資訊        }        private void checkActivity(){            //調用活動介面,看該訂單對應的商品是否有活動資訊        }    }

createOrder()方法中保持了抽象的一致性(增加代碼的可閱讀性,方便維護),但是裡面的私人方法createOrderInfo()裡面裡面又有一個私人方法。如果這種情況很多的話,那麼這個類就會變成一個私人方法很多的類。這個時候我覺得應該在service和dao中再增加一層,該層的抽象層次在service和dao之間。這樣子的話,我們就可以把一些業務封裝在該層，增加代碼的可讀性和維護性至於擴充性我目前還沒有想到哪個情境可以增加擴充性。

不知道你們對這個是怎麼看的。

回複內容：

業務分層思想

根據MVC分層思想，我們的項目都會分成3層，而業務層是在M裡面的。
現在的項目都會把M分層兩層即DAO層(持久層)和Service層(業務層)。
由於業務的發展,Service層裡面的業務會越來越複雜,這個時候為了保持Service層方法的抽象層次一致性,一般我們都會寫成堆成堆的private方法，舉個例子。

    public class OrderServiceImpl implements OrderService{        public void createOrder(){            checkActivity();            createOrderInfo();            createTrade();        }        private void createOrderInfo(){            createOrderInfo();            createSkuInfo();        }        private void createOrderInfo(){            //建立訂單資訊        }        private void createSkuInfo(){            //建立訂單對應單個SKU資訊        }        private void createTrade(){            //調用支付介面,建立支付資訊        }        private void checkActivity(){            //調用活動介面,看該訂單對應的商品是否有活動資訊        }    }

createOrder()方法中保持了抽象的一致性(增加代碼的可閱讀性,方便維護),但是裡面的私人方法createOrderInfo()裡面裡面又有一個私人方法。如果這種情況很多的話,那麼這個類就會變成一個私人方法很多的類。這個時候我覺得應該在service和dao中再增加一層,該層的抽象層次在service和dao之間。這樣子的話,我們就可以把一些業務封裝在該層，增加代碼的可讀性和維護性至於擴充性我目前還沒有想到哪個情境可以增加擴充性。

不知道你們對這個是怎麼看的。

1.個人認為，MVC裡面，control，service，dao都屬於控制層。前端介面作於view，資料庫充當Model的角色
2.在service裡面有很多private方法其實沒有太大問題。如果需要可以增加manager這樣的層次對某些privae方法進行封裝。但是層次分的太多，在實際開發的時候就會覺得很繁瑣，一個小功能就需要來幾個層次間串。其實也是一種維護和開發成本。
3. 一般事務的界限會劃分在service層的public方法，所以寫private方法的時候要小心，不然嵌套在一起會出現一些問題。

1. 同意 閑讀歲月 的觀點: MVC裡面，control，service，dao都屬於控制層。前端介面作於view，資料庫充當Model的角色
2. 如果service裡的private方法都只有在這個service中存在，即其他service不會也有代碼相同或類似的private方法，那我感覺寫private方法沒有什麼問題，如果其他service中也有和這個service中private方法相同的代碼，可以考慮單獨抽出一層。

service裡的每個方法只完成一個商務邏輯，如果商務邏輯比較複雜，可以考慮拆分成一個helper或者manager來專門處理這個複雜的邏輯，service就清清爽爽了，而不用一大堆的private方法在service裡了。

service建議做成一個facade，僅僅是其他業務操作的組合，控制事務用的。商務邏輯實現可以放到domain或者command裡頭。

個人感覺再拆分一層沒有必要，寫個helper類就差不多了，一個service的代碼過長可以多拆分幾個service，比如說orderservice可以拆分成ordermakeservice,ordercancelservice。平行拆分和再加一層拆分比較起來，平行拆分更好理解業務。

