[Feature request] 建议把CRUD装饰器升级为RestController

[jiangzm]

The feature, motivation（功能、动机）

当前CRUD和Controller 装饰器分开描述，如果打包成一个装饰器更方便，比如RestController。那CRUD组件也可以改成Rest，RestController 兼容 Controller 参数同时合并 CRUD 参数。

@RestController('/api/users', {
  tagName: 'users',
  model: UserEntity,
  service: UserRestService
})

Alternatives（替代方案）

No response

Additional context（其他上下文）

No response

[czy88840616]

这个方向可以考虑，不过建议先拆成两层来看。

第一层是 CRUD 路由能力本身，比如 RESTful/RPC/custom path、service 属性名等，这部分可以先看 #4609，目前还是 open，合并前先不要按已经支持来使用。

第二层是 RestController 这类合并装饰器语法糖。@Controller 现在承载的是框架路由能力，比如 prefix、middleware、version、routerOptions 等；@Crud 承载的是 model/service/dto/query 等 CRUD 元数据。直接合并会让语义和兼容性变复杂，所以更适合等 CRUD API 稳定后，再做一个很薄的组合封装。

命名上我也倾向先不要叫 RestController，因为 CRUD 未来可能有 RESTful/RPC/custom 等模式，CrudController 或类似名字会更准确一些。当前推荐仍然是 @Controller + @Crud 分开写。

[jiangzm]

嗯 了解。保留crud组件命名使用@CrudController 是比较统一的也不具破坏性。crud选项也可以考虑和控制器选项分开 比如 @CrudController(prefix, crudOptions, routerOptions) 或者 @Controller / @CrudController 增加 crud 对应CrudOption， 这样就是属性路径深了一层。 目前来说这个需求不迫切，因为在应用层使用装饰器合并 Controller() 和 Crud() 也是可以的。

[czy88840616]

我这么设计，是想着 curd 可以单独给类似 admin 的服务来使用（admin 在路上了），抽象各种 dto 层。