在Vaadin View类中应调用REST Controller还是直接使用Service类？

• 直接调用Service的潜在问题

  • 绕开REST层的统一逻辑：REST Controller里通常会做请求参数校验、全局异常处理、权限拦截（如Spring Security的接口校验）、请求日志埋点等，直接调用Service会导致Web UI和移动端的业务入口逻辑不一致——比如移动端请求会被权限拦截，而Web UI直接调用Service可能跳过校验，引发权限漏洞；异常处理也会出现差异，移动端收到标准化的错误响应，Web UI却要单独处理Service抛出的异常。
  • 破坏分层架构设计：原本的分层逻辑是「UI层（Vaadin/移动端）→ 控制层（REST Controller）→ 业务层（Service）」，跨层直接调用Service会让UI层和业务层耦合度升高，后续Service层的业务逻辑变动时，Web UI需要直接调整，而通过REST接口调用的话，只要接口契约不变，UI层无需修改。

• 推荐的两种方案

  • 统一调用REST接口：让Vaadin View和移动端一样，通过HTTP请求调用REST接口，这样所有入口复用同一套校验、权限、异常处理逻辑，保证业务规则的一致性，也符合架构分层的设计原则。
  • 新增客户端适配器层：如果觉得HTTP调用开销略大，可以在Vaadin层和Service层之间封装一个适配器类，在适配器里复用REST层的校验、权限逻辑（比如把REST中的校验逻辑抽成公共Validator组件），再调用Service。这种方式既避免了跨层耦合，又减少了HTTP调用的开销。

• 特殊场景的例外情况

  • 如果项目业务逻辑非常简单，没有复杂的权限、校验需求，且Vaadin与Service处于同一Spring上下文，直接调用Service可以快速实现功能，但这种做法不适合长期维护的中大型项目，建议还是保持分层的清晰性。

内容的提问来源于stack exchange，提问作者Emre Akburakcı