从今天开始我们开始介绍模型，模型是一个框架中非常重要的一块儿，控制器实际上不能进行数据的处理，这种处理的过程我们全部放在模型这一块儿来做。

        如果是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这个模型来举例，这个类的基本信息如下：

 

       我们用$_pk这个变量代表这个表的主键，将表的信息存储在$_tableInfo中，$_tablePrefix代表表前缀，它可以防止多个应用的表重名，$_tableName，逻辑上这个表的名字，物理上表的名字为$tablePrefix . $_tableName,当然，你也可以定义$_tableSuffix。

        对于关系模型来说，User表和Limits表之间的关系就是lid,所以，这个关系模型就可以写成这样：

     array(			'uid','userName','password','lid'		),		'Limits' => array(			'lid','limits'		)	);		private $_mainTable = 'User';}

         这里的$_tables指定到底是哪两个表之间的关联，$_tablesInfo还是指明表的基本信息，$_mainTable指明到底那一个表是主表。

         如果现在模型这一层就抽象成这样，那么假设在控制器中就直接实例化一个表模型或者关系模型，还是举一个例子吧！

         假设在User模型中有一个 方法login来完成登录，返回值为bool,这个方法的具体实现我们不管，那么在控制器中的代码如下：

    login($userName,$password)) {				//Success，然后设置session或cookie，跳转			} else {				//Fail，跳转			}		}	}}

         这样做有什么问题吗？

          1. 对于表模型来说，login这个单词不太恰当，login这个词与业务关联太大，对于一个简单的表模型来说，最好能够很好的和业务隔离，它只完成一些基本操作；

          2. 如果现在不是直接访问DB，而是首先在memcache中查看是否有这个key,如果有，直接从memcache中去，如果没有，访问DB，然后将值设置到memcache中，然后返回，这种情况，就只有在控制器中写很多本来不属于控制器该写的代码了；

          所以，这儿，我们再抽象出来一层，这一层处于控制器和表模型与关系模型之间，这样，控制器直接访问的是这一层，这一层跟业务紧密结合，就可以让表模型和关系模型从复杂的业务中脱离出来，这样以后对于项目的扩展很有帮助。

           还是使用刚才这个例子，假设这个类的名字为UserModel，那么它的代码如下：

         

    isPasswordCorrect($userName,$password)) {			//设置cookie或session，不写了			return true;		} else {			//密码不正确			return false;		}	}}

           这样控制器这一块儿的代码就变成这样了：

    login($userName,$password)) {				//Success，跳转			} else {				//Fail，跳转			}		}	}}

            控制器中没有业务逻辑的处理代码了，User这个类的命名也变得很有意义了,isPasswordCorrect。

            我们将处于控制器和表模型与关系模型之间的这一层称为模型（和Java的service这一层很类似），这样，对于编写控制器的程序员来说，它只需要查看模型这一层的代码就可以了，到底模型这一层调用的是关系模型或者表模型都没有关系。

            实际上我们现在将模型完全看成了对DB的操作了，实际上模型不一定是操作DB的，现在我们还可以考虑一下，在模型这一层将Cache抽象出来，现在编写一个cache的接口ICache：

           然后针对不同的Cache，只要实现这个接口即可。

           刚才我们考虑的是Cache，实际上还有nosql，现在有很多nosql，我们可以将一些共有的操作抽象出来变成INosql，当然，这儿我就不写了。

           好吧，又超时了，就写到这儿吧！！！

           PS：这一次的所有代码都是现场写的，没有去检查是否有语法错误等，大家看看思路就行。