# Niushop開源商城調用原理
---
### 1. **常見小型系統的利弊分析**
一般的小型業務系統，大多數的設計是這樣的
Controller \(Model +DAO\)---> View
在控制器內同時實現數據業務邏輯（Model +DAO）的處理方式，把處理結構反饋給視圖層來渲染顯示。對于業務邏輯不是非常復雜的系統完全可以采用這樣的簡單設計來實現。這樣做的好處是編寫簡單，容易理解，需要進行代碼編寫處理的地方相對集中。
例如：實現一個訂單的創建業務
```php
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個職責，既負責視圖的顯示控制，又充當數據及業務邏輯的處理。導致代碼耦合性太大。
### 2. **Niushop采用 數據業務層 \(Service層\)單獨分層的設計架構模式**
**Model ---> DAO ---> Service ---> Controller ---> View**
后臺view層直接調用通過控制器返回的數據，但是控制器不直接書寫業務邏輯，而是將業務邏輯功能放在service層進行調用
前臺需要模板靈活，系統3.0版本進行升級，專用api接口，而不是控制器加載數據，這樣保證了系統的靈活性。
