Niushop采用 數據業務層 (Service層)單獨分層的設計架構模式 一般的小型業務系統，大多數的設計是這樣的 Controller (Model +DAO)---> View 在控制器內同時實現數據業務邏輯（Model +DAO）的處理方式，把處理結構反饋給視圖層來渲染顯示。對于業務邏輯不是非常復雜的系統完全可以采用這樣的簡單設計來實現。這樣做的好處是編寫簡單，容易理解，需要進行代碼編寫處理的地方相對集中。 例如：實現一個訂單的創建業務 ~~~ namespace app\Order\controller; class Order { public function CreateOrder() { Db::startTrans(); try{ //步驟一創建訂單 $order = new Order; $order->orderId = '20170601000001'; $order->order_date = 'now'; $order->save(); //步驟二創建訂單項 foreach($orderItem in $items){ $item = new OrderItem; $item->orderId = $order->orderId; $item->order_itemid = $orderItem->id; $item->save(); } // 提交事務 Db::commit(); } catch (\Exception $e) { // 回滾事務 Db::rollback(); } return 'Order_Create'; } } ~~~ 這樣的實現方式已辦理說是沒有問題。可是如果有這樣的情況，比如希望在創建購物車的時候也需要添加訂單項，這個時候上面的創建訂單項又要重寫一次。還有情況是用戶在修改訂單的時候也希望創建一個訂單項，這個時候同樣的方法又需要調用。如果像上面寫法，這樣會出現創建訂單項的代碼冗余調用。假如訂單項屬性字段很復雜，由于代碼冗余造成的維護和出錯率會越來越大，所以上面的設計方式就不太適合了。同時這樣設計有一個問題就是本來控制器的作用是數據和視圖的中間傳遞著，現在控制器充當2個職責，既負責視圖的顯示控制，又充當數據及業務邏輯的處理。導致代碼耦合性太大。 Model ---> DAO ---> Service ---> Controller ---> View