淺談代碼分層 非ORM 愈來愈穩定

需求一：

boss初期要求，咱們要設計一個用戶管理系統，我須要他們的基本信息。

我開始寫最簡單的用戶模型(信息模型和操做模型)。

<?php
//操做模型  面向操做
interface IMemberAction{
  function get($params);//獲取用戶 之後不知道會用什麼來獲取
  function add();//新增用戶
  function remove();//刪除用戶
  function listing();//用戶列表
  function remove($params);
} 
//信息模型 面向數據庫
interface IMemberModel{

   function insert();
   function delete();
   function update();
   function select();
   //這裏是最基本的 固然還會有left join等
}

接着在操做模型的基礎上創建Service層  在信息模型上創建Dao層   這兩層是交互的

class MemberAction implemetns IMemberAction{

    public function add(){
      new MemberDao.insert();
    }
    
    public function remove(){
      new MemberDao.delete();
    }
}

class MemberDao implements IMemberModel{
   
      public function insert(){
       new Db.insert();
      }
}

//以後是瀏覽器與對接的控制器(調用service和視圖，傳遞參數但不涉及邏輯處理) 權限控制在這裏

class MemberController{

   public function add(){
   
     new MemberService.add($_POST['params']);
     include 'temp.tpl';
   }
}

好了，boss的需求咱們已經完成了，但事情還沒完,過幾周後，

需求二：

boss說，我須要他們分等級，分部門，主管能夠管理下面的人（刪除、增長，考覈業績（業績表））。

分析：這個時候的對象是多人了，是用戶爲主體。

這個時候改變的第一個要素就是數據庫結構，數據庫結構上面我要變了，增長了部門，和等級（確定要新增表了）。

問題產生了。

一、添加用戶的時候，要新增部門，並且是多表。

二、業績也是多表。

這個時候千萬別去改動原來的模型。這裏是面向對象的組合型

新增部門數據模型

新增業績數據模型

新增部門操做模型

新增業績操做模型

原有的用戶數據模型

原有的用戶操做模型

接下來是service層。分平行2層

用戶與部門service層。

用戶與業績service層。

最後設置視圖和控制層。

需求三：

沒過幾天boss又有需求，想要知道部門的業績及統計考覈。

這個時候你只須要新建一個控制層和視圖層，調用部門service和業績考覈service便可。

總結：

一開始的分層，對之後的需求是很是大的幫助的。

何時分層。

一、傳遞參數和視圖分層

二、面向數據庫仍是面向操做分層

三、表與表之間用