浅谈代码分层 非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便可。

总结：

一开始的分层，对之后的需求是很是大的帮助的。

何时分层。

一、传递参数和视图分层

二、面向数据库仍是面向操做分层

三、表与表之间用