一步步编写PHP的Framework(十五)

 

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

        如果是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，当然，这儿我就不写了。