## 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