controller和service都有参数校验需求，应该怎样设计？

service 要考虑的是可以在多个地方复用，大多开源的项目 service 都不是这样考虑的。看项目情况吧

你要是多处调用service最好是方法兼容 而不是service使用验证

可能其他人在调用的时候并不清楚参数的格式，给了错误的参数

我们不必为别人的愚蠢负责

前提是你写好了对应的注释和结构，原本一个注释就可以解决的问题，为什么要搞得这么麻烦。

其次 如果你考虑抽象封装，那就加一个 DataTransfer，你 Service 接到的是一个 DataTransfer，并不是单独的数据，直接，验证逻辑完全交由 DataTransfer 来做。将职责清晰划分后，就明了多了。职责如下

1. Controller 接受数据
2. Controller 组装数据并生成 DataTransfer
3. DataTransfer Validate
4. 调用 Service 并传入 Transfer

EX：

use ExampleDataTransfer;
use ExampleService;

class ExampleController extends Controller
{
    public function test(Request $request, ExampleService $service)
    {
        // Choose 1
        // You can handle other logic through the request or others on this step
        // other ligic begin
        //todo handle other logic
        // other ligic finished
        $data_transfer = new ExampleDataTransfer($request->all());
        $data_transfer->validate(); // Throw the ValidationException if failed
        // Choose 1
        $service->transfer = $data_transfer;
        $service->callMethod();
        //Choose 2
        $service->callMethod($data_transfer);
    }
}

总的来说，在控制器层和在服务层校验我觉得都可以，但是我自己的项目都是在控制器层验证的。

Larave也设计了专门的校验类，注入到控制器中，我觉得还是挺方便的，但是简单的校验我也不写专门的校验类，比如只有一个参数而且判断也很简单，我就直接写控制器里。

写控制器的好处就是：服务层那里不需要再做校验了。

只需要关心 controller 数据校验，校验完的数据才会流转到service 服务中。 业务数据，业务层处理，服务层数据只是为了复用封装。

把你需要的业务条件在service判断一下，不存在抛异常。不应该走到sql层报错的，只要你的异常抛的正确，复用该service的才能根据错误进行修正。