phalapi-进阶篇1(Api,Domain,和Model)

[7.7]-三层结构Api,Domain,和Model - 图1

前言

先在这里感谢phalapi框架创始人@dogstar,为我们提供了这样一个优秀的开源框架.

本小节已经步入了进阶篇,在进阶篇中会着重谈论一些框架中运用的一些好的思想并且进行解读,本小节主要是讲解在Phalapi框架中推荐使用的三层结构Api+Domain+Model将从各个角度和整体角度进行讲解.

附上:

喵了个咪的博客:w-blog.cn

官网地址:http://www.phalapi.net/

开源中国Git地址:http://git.oschina.net/dogstar/PhalApi/tree/release

1. Api+Domain+Model

其实这样的三层结构和java中的web+service+dao比较像只是说web和api一个进行页面显示一个不进行页面显示这个区别,在着重讲一下这三层在Phalapi中分工是怎么样的,他们分别担当者什么样的角色,需要做什么样的事情.

1.1 Api层

为什么说Api层像java中的web层呢,因为他们有一个共同的特性就是接受请求和返回结果.只不过java中没有表现得那么强烈,它会通过控制器把请求转发到service层作处理,并将处理结果在页面展示,所以Api更像担当控制器的作用.

Api层中需要做的事情如下:

  • 注册接口/定义接口和控制请求参数

这是首先要做的事情,和在web中的url一样,就是添加需要接受的参数以及对参数进行验证,如下:

public function getRules(){
return array(
'index' => array( //定义接口名
//添加参数验证机制
'username' => array('name' => 'username', 'default' => 'PHPer',),
),
);

}

  • 进行业务/逻辑的拼接

在这里进行业务/逻辑拼接,比如说是查询列表接口需要做两件事情,第一验证用户(是否存在或是否有权限),第二查询出应该返回的列表,应该是如下样式:

//验证用户
$Domain_Developers = new Domain_Developers();
$Domain_Developers->checkDev($this->dId);
//获取用户的APP列表
$Domain_App = new Domain_App();
$Domain_App->getMyAppList($this->dId);

  • 返回结果

返回结果就比较简单了,就是把你经过上面拼接处理后获得的数据返回,如下:

return $data;

1.2 Domain层

Domain层主要负责的是具体的业务实现,如用户验证,一个Domain方法就是一个小的业务具体实现(注意尽量把业务划分得细一点方便通用)

  1. /**
  2. * 用户验证
  3. */
  4. public function checkDev($dId){
  5. //通过ID 获取用户
  6. $Model_Developers = new Model_Developers();
  7. $dev = $Model_Developers->checkDevdId($dId);
  8. //用户不存在处理
  9. if(!$dev){
  10. throw new PhalApi_Exception_BadRequest(T('No Dev'), -1);
  11. }
  12. }

1.3 Model层

Model层其实无需多讲,也就是把数据库操作单独提炼出来统一处理,如下:

  1. /**
  2. * 验证用户存不存在
  3. */
  4. public function checkDevdId($dId){
  5. return $this->getORM()->select('dId')->where('dId', $dId)->fetch();
  6. }

2. 三层结合使用的好处

  • 结构清晰,互不干扰

就我个人感觉来说,在实际开发中使用这样的三层结构带来的最大的好处在于结构清晰,为什么这么说呢,因为每一层需要做的事情都是非常独立的,你永远不会在API层中看到数据操作的代码,所以在排查问题的时候,如果是数据出了问题,肯定不会去API层里面去找,这样就非常方便错误的定位,再者就是代码可读性非常高,相对于mvc框架来说这样的好处是非常明显的.

  • 高度解耦,灵活高可用

带来的第二个很重要的好处就是解耦和高可用,高可用体现在Api可以重复利用Domain,Domain可以重复利用Model,这样可以减少很多不必要的代码量.如果相互的关系仅仅只是拼接(除非是结果会互相影响)的情况下就实现了解耦.

  • 分工合作,提高效率

在有这样的一套规范之后在分工合用时,对方不需要去看你的代码具体实现了什么,只需要看你这个方法干了什么,直接拿起来用就可以了,当然是在业务划分成小块的情况下,而且可以很明确的划分出来模块,当你需要用到对方的模块的时候只需要让对方提供即可,这样可以增加模块的专注性,从而提高合作开发的效率.

3. 总结

其实在刚刚接触这个框架的时候,我也是特别不能理解这样划分的作用,在后面的开发和别人的交流中进行了一些尝试后,发现这样用起来确实有很多的好处,希望今天的教程能让大家理解这样的一种规范可以带来很多的好处,并且自己去尝试和使用.

注:笔者能力有限有说的不对的地方希望大家能够指出,也希望多多交流!

官网QQ交流群:421032344 欢迎大家的加入!

原文: https://www.phalapi.net/wikis/7-7.html