大家都是怎么设计项目中的传参的？

这就好比Request，有的人就喜欢封装，写多了基本一个接口定义一套，我是觉得很麻烦 :joy:我们之前传params的情况会在注释里把params的字段都列出来，方便后面人维护调用。现在的情况是代码没人review自己定义，我是参数少的，多参数接收传递，加个默认值然后empty判断，参数多的写params，用的时候判断下，必备不存在的还是优先返回，能跑就行

为此我设计了一个灵活的 DTO ，完全借鉴了 Laravel 的 Attribute

我用 Request/JsonRequest， 在开头获取所有会用到的数据

感觉想太多了，一般情况下Request文件里面就已经包含了所有参数

那么多参数，那么可能要做优化了。

现在升级到 PHP 8 之后，完全可以使用命名参数

一般接口控制器层面，每个 action 都会有对应的 Request 类吧，如果是这种开发方式，可以将 Request 类和 DTO通过反射结合起来就好了，字段名称只需要定义一次，Service 里面使用 DTO

DTO

class UserDTO extends AbstractDTO{
        #[Validate(rules:['required'])]
        public ?string $nickname,
        public ?string $birthday,
        public ?int $city_id,
        public ?int $height,
        public ?int $weight,
        public ?int $profession_id,
        public ?int $gender
}

Request
通过上面的 DTO 反射生成 Request 类

class UserRequest extends AbstractRequest{
      protected string $dto = UserDTO::class

       public function rules():array{
        // 通过反射生成
      }

      public function getDto():AbstractDTO{
            return new {$this->dto}($this->validated());
      }
}

Controller

class UserController {

   public function user(UserRequest $request){
        $this->userService->user($request->getDto());
   }
}

Service

class UserService {
     public function user(UserDto $dto){
            // ....
     }
}

听大家推荐过但目前还没用这个包。PHP 的关联数组无法进行元组类型约束那样的效果，肯定还是传对象进行约束更好，也便于一些框架进行编排或进行静态分析。

我的习惯是不太关注文件的多少，当发现重复代码，可以通过 Trait 或 继承 抽象化来实现 DRY （Dont Repeat Yourself）。

可以只在在 service 层面 做 入参控制

// service
function action(Data $data){ 
// ...
}

在 controller 层 用 request 来控制 入参

// controller

function update(Request $request){

    // 直接采用请求的数据
   $data =  Data::form($request);

   // 自行设置
   $params = $request->all();
   $params['user_id'] = $request->user()->id;
   $data = Data:form($params);
   // 或者使用 additional 追加额外数据
   $data->additional([]);

   $this->service->action($data);

}

controller 只负责对请求参数的一些简单组装操作，业务的参数在 DTO 或者 service 内校验

要求语义化，扩展性好，可读性高，这必须OOP，每个方法定义个独立的参数类，自己封装下好了。

你可以参考laravel表单验证，每个action定义个独立的request类，定义好参数属性。