代码分层设计实践与总结
简介
见过很多PHP开发者的代码，在代码分层上面都不是很注重。一般都是控制器负责所有的业务逻辑，在控制器中调用模型做数据操作、验证数据也在控制器中等等情况。这样的做法怎么说呢？也没错，但是这样写代码就显示的很杂糅。
本文分享一些个人的代码分层想法，存在不足的地方，希望大家多多提出一些宝贵建议。
文章底部有代码示例连接，可以直接通过代码查看或许更加方便。
相关技术
Laravel资源控制器、Laravel模型、PHP对象接口
实现思路
大致实现的思路如下：
// uml图
@startuml
controller->service:调用
service->repository:调用
repository->model:调用
@enduml
controller层直接调用service层，controller主要负责传递请求参数，返回接口数据。 service层负责处理数据逻辑，将controller接收到的参数格式化，然后将整理好的数据传递给repository层。 repository层直接调用model层的示例，进行数据操作。 model层主要责任是映射数据表，定义一个有关数据表的操作。例如表名、时间错、获取器和修改器等等。
代码演示
首先定义了如下的目录结构，具体的其他结构可以根据自己的需要来定义，例如验证层、接口响应层、资源层等等。
为了保证在controller、service、repository层中的相关方法名称以及返回参数格式都保持一致，在每一个层，都定义一个接口，接口中的方法都定义好参数格式以及返回值类型。例如controller层。首先我们定义一个controller层接口.
<?php
namespace App\Http\Controllers;
/**
* Api controller service
*
* Interface ApiServiceController
* @package App\Http\Controllers
*/
interface ApiServiceController
{
/**
* 具体每个方法的定义参考laravel文档
* https://learnku.com/docs/laravel/5.8/controllers/3893#resource-controllers
*/
public function index();
public function create();
public function store();
public function show();
public function edit();
public function update();
public function destroy();
}
对应的实现类controller，实现ApiServiceController接口。
<?php
namespace App\Http\Controllers\User;
use App\Http\Controllers\ApiAuthBaseController;
use App\Http\Controllers\ApiServiceController;
use App\Services\UserInterface;
/**
* User's controller
*
* Class UserController
* @package App\Http\Controllers\User
*/
class UserController extends ApiAuthBaseController implements ApiServiceController
{
public function __construct(UserInterface $apiService)
{
$this->service = $apiService;
parent::__construct($apiService);
}
public function index()
{
$items = $this->service->serviceIndex((array)$this->requestParams);
return response()->json([
'code' => 10001,
'msg' => 'select success',
'data' => $items,
]);
}
public function create()
{
// TODO: Implement create() method.
}
public function store()
{
if ($this->service->serviceStore((array)$this->requestParams)) {
return response()->json([
'code' => 10001,
'msg' => 'create success',
'data' => [
'id' => 1,
],
]);
}
}
public function show()
{
// TODO: Implement show() method.
}
public function edit()
{
// TODO: Implement edit() method.
}
public function update()
{
if ($this->service->serviceUpdate((array)$this->requestParams)) {
return response()->json([
'code' => 10001,
'msg' => 'update success',
'data' => [
],
]);
}
}
public function destroy()
{
if ($this->service->serviceDestroy($this->requestParams)) {
return response()->json([
'code' => 10001,
'msg' => 'delete success',
'data' => [
],
]);
}
}
}
对应的service层、repository层都根据类似的方式定义。具体的实现方法可以参考文章底部的代码示例。
接口调用演示
根据上面的代码演示逻辑，假设我们定义好了service层和repository层对应的逻辑，这时候我们Api添加一个资源路由的定义就可以直接调用啦。在api.php路由文件定义如下格式：
<?php
use Illuminate\Support\Facades\Route;
Route::resource('user', 'User\UserController');
接下来，我们查看一下调用结果。1.增加数据。
2.删除数据。
3.修改数据。
4.查询数据。
总结
本文总结只是属于个人的一些总结，存在不足的地方，欢迎大家指正。这里总结一下设计这一的思路。
使用资源路由，我们直接定义一个路由规则，增删改查等接口方式，我们就自动实现并且能够规范团队中的接口，同时也符合RESTful API的规范。
使用接口定义一些业务逻辑函数，实现类直接实现接口中的方法，这样可以避免团队方法定义不一致、接口参数不一致、返回参数不一致等情况。如果接口中方法没有定义，然而业务逻辑需要单独一个方法，可以直接在实现类中定义独有的方法即可。
model层主要实现表映射关系，这里直接把表当做模型。因此所有的逻辑不应该在模型层中处理，顶多定义一个属性等情况。repository层直接去调用model层，不需要处理数据格式等情况，根据service层传递的条件，将查询的数据直接返回给service层。service层则是负责业务逻辑处理，比如格式化接口请求参数、组装查询条件、删除条件等情况。controller则是负责将请求的参数传递给service层，然后将service层返回的数据返回给客户端。这样每一层负责的职能独立，互补关联。降低了代码的耦合度。
使用资源路由，简化接口。
示例代码
代码地址https://gitee.com/bruce_qiq/laravel-design