Restful Spring Boot Web 应用程序中的控制器-外观-服务架构
我正在使用 Spring Boot 为 Web 应用程序开发一组微服务，我不确定我使用的模式设计是否正确、是否有意义或是否具有任何优势。
我使用的是控制器-外观-服务设计，在我看来，它应该以这种方式工作：
- 控制器将所有内容委托给外观，将输入 DTO 传递给它
- 外观实现所有业务逻辑并使用一个或多个服务创建输出 DTO 以发送回控制器
- 服务实现核心和原子功能，主要是 CRUD，没有任何或最少的业务逻辑，以便具有不同业务逻辑的不同外观可以使用它们，并向外观返回 JPA 实体
是这样的一个好的设计模式？门面是不必要的吗？
更具体地说，业务逻辑应该在外观中还是在服务中？我认为服务应该是逻辑不可知的，以便它们可以在多个外观之间共享，这些外观可以根据端点实现不同的逻辑。
另外，在 CRUD 操作的情况下，服务是否应该将实体返回到外观？或者应该由服务来为外观创建输出 DTO？
I'm developing a set of microservices for a web application with Spring Boot, and I'm unsure if the pattern design I'm using is correct, or makes sense, or has any advantages.
What I'm using is a controller-facade-service design, which in my mind should work in this way:
- The controller delegates everything to the facade, passing the input DTO to it
- The facade implements all the business logic and uses one or more services to create an output DTO to send back to the controller
- Services implement core and atomic functionalities, mostly CRUDs, without any or minimal business logic so that different facades with different business logic can use them, and return a JPA entity to the facade
Is this a good design pattern? Is the facade unnecessary?
More specifically, should the business logic be in the facade or in the service? I believe services should be logic agnostic so that they can be shared across multiple facades, which may implement different logic depending on the endpoint.
Also, in the case of a CRUD operation, should the service return an entity to the facade? Or should it be up to the service to create an output DTO for the facade?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论