浅谈代码分层 非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说，我需要他们分等级，分部门，主管可以管理下面的人（删除、增加，考核业绩（业绩表））。

分析：这个时候的对象是多人了，是用户为主体。

这个时候改变的第一个要素就是数据库结构，数据库结构上面我要变了，增加了部门，和等级（肯定要新增表了）。

问题产生了。

1、添加用户的时候，要新增部门，而且是多表。

2、业绩也是多表。

这个时候千万别去改动原来的模型。这里是面向对象的组合型

新增部门数据模型

新增业绩数据模型

新增部门操作模型

新增业绩操作模型

原有的用户数据模型

原有的用户操作模型

接下来是service层。分平行2层

用户与部门service层。

用户与业绩service层。

最后设置视图和控制层。

需求三：

没过几天boss又有需求，想要知道部门的业绩及统计考核。

这个时候你只需要新建一个控制层和视图层，调用部门service和业绩考核service即可。

总结：

一开始的分层，对以后的需求是非常大的帮助的。

什么时候分层。

1、传递参数和视图分层

2、面向数据库还是面向操作分层

3、表与表之间用