如果是Java，即使是没用框架，它的模型这一块儿也挺复杂的，首先编写service接口，然后写实现，然后定义DAO接口，DAO实现，然后定义这几层之间传输数据的Domain，一般我认为它就是一个POJO。
Java这种契约式的编程方式很不错，即使后面的实现类发生改变，接口没有改变，代码的修改的量也不是很多。
在PHP这一块儿，相对而言就要弱一些，我们如果将这个抽象的太深，那么效率必然会收到影响，抽象的比较浅，模型这一层后期维护又是一个问题。
首先我们先说一下最常用的方式，访问DB，如果只是着眼于单个表，那么就存在表模型，一个表就是一个模型，我们称为DbTable；如果着眼于表与表之间的关联，那么就存在关系模型，我们称为DbRelation。
由于DbTable只与单个表有关，所以它的操作比较简单，而DbRelation由于处理的是表与表之间的关系，所以比较复杂。
现在我们举一个例子，一个系统有三个角色，管理员，普通用户，游客，而这三个角色的基本信息是相同的，所以DB中相应的有两个表：
1. User表，存放用户的基本信息，假设有以下字段：
uid userName password lid
注：lid在逻辑上是后面我要说的Limits表的外键。
2. Limits表，存放用户的权限信息，有以下字段：
lid limits
limits是一个int类型的值，假设1代表普通用户，2代表管理员，由于游客在User表中没有记录，所以就不记在这个表中。
那么对应的模型有:
表模型有两个：User和Limits。
现在我们以User这个模型来举例，这个类的基本信息如下：
| 1 |
| 2 | class User { |
| 3 | private $_pk = 'uid'; |
| 4 | private $_tableInfo = array( |
| 5 | 'uid','userName','password','lid' |
| 6 | ); |
| 7 | private $_tablePrefix = ''; |
| 8 | private $_tableName = ''; |
| 9 | } |
我们用$_pk这个变量代表这个表的主键，将表的信息存储在$_tableInfo中，$_tablePrefix代表表前缀，它可以防止多个应用的表重名，$_tableName，逻辑上这个表的名字，物理上表的名字为$tablePrefix . $_tablePrefix,当然，你也可以定义$_tableSuffix。
对于关系模型来说，User表和Limits表之间的关系就是lid,所以，这个关系模型就可以写成这样：
| 01 |
| 02 | class Lid { |
| 03 | private $_tables = array( |
| 04 | 'User','Limits' |
| 05 | ); |
| 06 | private $_tablesInfo = array( |
| 07 | 'Users' => array( |
| 08 | 'uid','userName','password','lid' |
| 09 | ), |
| 10 | 'Limits' => array( |
| 11 | 'lid','limits' |
| 12 | ) |
| 13 | ); |
| 14 | private $_mainTable = 'User'; |
| 15 | } |
这里的$_tables指定到底是哪两个表之间的关联，$_tablesInfo还是指明表的基本信息，$_mainTable指明到底那一个表是主表。
如果现在模型这一层就抽象成这样，那么假设在控制器中就直接实例化一个表模型或者关系模型，还是举一个例子吧！
假设在User模型中有一个 方法login来完成登录，返回值为bool,这个方法的具体实现我们不管，那么在控制器中的代码如下：
| 01 |
| 02 | class IndexController extends Controller { |
| 03 | public function index() { |
| 04 | $userName = empty($_GET['userName']) ? null : trim($_GET['userName']); |
| 05 | $password = empty($_GET['password']) ? null : trim($_GET['password']); |
| 06 | if((null === $userName) (null === $password)) { |
| 07 | //跳转 |
| 08 | } else { |
| 09 | $user = new User(); |
| 10 | if($user->login($userName,$password)) { |
| 11 | //Success，然后设置session或cookie，跳转 |
| 12 | } else { |
| 13 | //Fail，跳转 |
| 14 | } |
| 15 | } |
| 16 | } |
| 17 | } |
这样做有什么问题吗？
1. 对于表模型来说，login这个单词不太恰当，login这个词与业务关联太大，对于一个简单的表模型来说，最好能够很好的和业务隔离，它只完成一些基本操作；
2. 如果现在不是直接访问DB，而是首先在memcache中查看是否有这个key,如果有，直接从memcache中去，如果没有，访问DB，然后将值设置到memcache中，然后返回，这种情况，就只有在控制器中写很多本来不属于控制器该写的代码了；
所以，这儿，我们再抽象出来一层，这一层处于控制器和表模型与关系模型之间，这样，控制器直接访问的是这一层，这一层跟业务紧密结合，就可以让表模型和关系模型从复杂的业务中脱离出来，这样以后对于项目的扩展很有帮助。
还是使用刚才这个例子，假设这个类的名字为UserModel，那么它的代码如下：
| 01 |
| 02 | class UserModel { |
| 03 | public function login($userName,$password) { |
| 04 | $user = new User(); |
| 05 | if($user->isPasswordCorrect($userName,$password)) { |
| 06 | //设置cookie或session，不写了 |
| 07 | return true; |
| 08 | } else { |
| 09 | //密码不正确 |
| 10 | return false; |
| 11 | } |
| 12 | } |
| 13 | } |
这样控制器这一块儿的代码就变成这样了：
| 01 |
| 02 | class IndexController extends Controller { |
| 03 | public function index() { |
| 04 | $userName = empty($_GET['userName']) ? null : trim($_GET['userName']); |
| 05 | $password = empty($_GET['password']) ? null : trim($_GET['password']); |
| 06 | if((null === $userName) (null === $password)) { |
| 07 | //跳转 |
| 08 | } else { |
| 09 | $userModel = new UserModel(); |
| 10 | if($userModel->login($userName,$password)) { |
| 11 | //Success，跳转 |
| 12 | } else { |
| 13 | //Fail，跳转 |
| 14 | } |
| 15 | } |
| 16 | } |
| 17 | } |
控制器中没有业务逻辑的处理代码了，User这个类的命名也变得很有意义了,isPasswordCorrect。
我们将处于控制器和表模型与关系模型之间的这一层称为模型（和Java的service这一层很类似），这样，对于编写控制器的程序员来说，它只需要查看模型这一层的代码就可以了，到底模型这一层调用的是关系模型或者表模型都没有关系。
实际上我们现在将模型完全看成了对DB的操作了，实际上模型不一定是操作DB的，现在我们还可以考虑一下，在模型这一层将Cache抽象出来，现在编写一个cache的接口ICache：
| 1 |
| 2 | interface ICache { |
| 3 | public function connect(); |
| 4 | public function get($name); |
| 5 | public function set($name,$val,$expire = null); |
| 6 | public function have($name); |
| 7 | public function remove($name); |
| 8 | public function clear(); |
| 9 | } |
然后针对不同的Cache，只要实现这个接口即可。
刚才我们考虑的是Cache，实际上还有nosql，现在有很多nosql，我们可以将一些共有的操作抽象出来变成INosql，当然，这儿我就不写了。
