在上一篇文章中讲述了我们编程代码为什么要这么做以及一些东西的区别，也说了很多开发者都是有一个很好的开头，但是很少有人能坚持和善尾。
当一个项目需求变的庞大时候，你会发现项目代码不自然的就变臃肿，那是因为一开始就没有制定一种架构制度规则在里面，所以会越写越乱越写越杂。如果一开始就制定了代码架构，并且在后续开发中顺着架构风格去开发，代码只会有效的扩展最后让整个架构变的饱满。而不会越写越乱，到最后东一块西一块，到处都是各种重复use或者随处new对象各种交错调用。
以下做法是博主分享的一些个人想法在里面。
控制器层：路由接收，任务派发。只use各类主服务文件
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
class LabelController extends AuthController { //添加业务 public function actionAdd() { $result = LabelsService::service(1)->add($this->request_params); } //修改业务 public function actionEdit() { $result = LabelsService::service(2)->edit($this->request_params); } //获取数据业务 public function actionList() { $result = LabelsService::service(1)->list($this->request_params); } //删除业务 public function actionDelete() { $result = LabelsService::service(1)->delete($this->request_params); } //详情展示业务 public function actionShow() { $result = LabelsService::service(1)->detail($this->request_params); } } |
主服务层：接收任务并且细化业务逻辑，分配调度相关子服务辅助处理。只use和自己相关的子服务和其他有关主服务，子服务无需开局全部use，按需激活即可。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
Class LabelsService extends BaseService { protected static $service = [ 1=>'app\modules\property\services\RoomLabelsService', 2=>'app\modules\property\services\ ', ]; protected $childservice; public function __construct($id) { $this->childservice = self::$service[$id]::service(); } public function add($data) { $this->childservice->insert($data); } public function update($data) { $this->childservice->edit($data); } public function delete($data) { $this->childservice->delete($data); } public function detail($data) { $this->childservice->show($data); } public function list($data) { $this->childservice->list($data); } } |
子服务层：所有子服务只为数据库操作提供服务并且各自只操作和自己相关的数据表。只use和自己相关的数据文件
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
Class RoomLabelsService extends BaseService implements Label { public function show() { echo'room_show'; } public function list() { echo'room_list'; } public function insert() { echo'room_insert'; } public function delete() { echo'room_delete'; } public function edit() { echo'room_edit'; } } |
仔细一想至少部分代码架构清晰了许多避免了许多乱调用的情况，也避免了很多乱use的载入。但是这样还不够,我们的主服务层会变的臃肿，假设在一个主服务文件中有10个相关联的子服务，那么就需要载入10个子服务随时调用，并且要对10个子服务写好对应的增、删、改、查。那代码臃肿就大大的增加了许多，所以这时候引入多态的思想，统一所有子服务的风格。
为了统一所有开发者的一致性所以只能采取定义标准接口的方法
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
interface Label { public function show(); public function list(); public function insert(); public function delete(); public function edit(); } |
所有子服务必须无条件的去 implements Label
这种方式其实就是很多代码中常用的多态思想，但是要注意一个子服务文件可能需要关联其他表文件。出现这种需求，我们也必须遵守想对应的架构风格，走主服务层去调用，主服务和主服务打交道，杜绝子服务和子服务打交道。如果数据表符合数据库设计规范，那么在主服务文件中完全可以抽出一个公共的方法来做子服务关联子服务的动作，那么必须所有表操作关联都使用模型操作并且所有命名必须有规则和规范。当一个子服务接收到请求可以很明确的直接关联出对应的表（所有关联用一个方法）。
如果想用上述方法来做代码层的架构，需要详细去完善考虑周全后在运用到实际开发中，本文主要是抛砖引玉。为了解决上一篇代码架构中提到的问题，实现方法没有正确的只有最合适的，博主的方法也只是一个参考。
一点PHP，一点技术分享。
