我们在构建Jhipster应用程序时如何选择业务逻辑?

huangapple go评论70阅读模式
英文:

How do we choose the business logic when building a Jhipster application?

问题

使用JHipster助手创建实体时,会询问:

? 是否要为业务逻辑使用单独的服务类? (使用箭头键选择)
> 不需要,REST控制器应直接使用存储库
  是的,生成一个单独的服务类
  是的,生成单独的服务接口和实现

在什么情况下我应该选择哪个选项?

每种解决方案的优缺点是什么?

一旦一切都设置好了,是否能轻松更改架构?

英文:

When creating a entity with the Jhipster helper, it asks

? Do you want to use separate service class for your business logic? (Use arrow keys)
> No, the REST controller should use the repository directly
  Yes, generate a separate service class
  Yes, generate a separate service interface and implementation

In which case should I use which option?

What are the benefits and flaws of each solution?

Is it possible to change easily the architecture once everything is set?

答案1

得分: 2

IMHO,这取决于您的应用程序要多么复杂以及您计划维护多长时间。

如果您的领域模型相当简单,您的 REST 控制器是直接的 CRUD 操作,没有复杂的映射,您可以不使用单独的服务层。

如果您的领域模型或交互变得更加复杂,您可能需要一种"关注点分离":您的控制器类应该只是将 REST 调用从/到正确的 DTO 进行映射,用于 REST API,而业务逻辑和不同实体之间的协调应该放在一个与 REST API 无关的服务类中。从长远来看,这使得在业务逻辑的更改与 REST API 的更改分开变得更容易。

一些要阅读的博文:

https://www.petrikainulainen.net/software-development/design/understanding-spring-web-application-architecture-the-classic-way/

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

然后是关于是否使用接口的决定。使用接口的主要优点过去是它允许更好的测试并避免了模块之间的耦合过于紧密。但自从2010年以来,关于它是否值得开销的讨论很多。也许可以开始阅读 Adam Bien 原始帖子下面的讨论:

https://www.adam-bien.com/roller/abien/entry/service_s_new_serviceimpl_why

英文:

IMHO it depends on how complex your application is going to be and how long you plan on having to maintain it.

If your domain model is quite simple and your REST controllers are straightforward CRUD operations without complex mapping, you can get away without using a separate service layer.

If your domain model or interactions get more complex, you might need a 'Separation of Concerns': your Controller classes should just map REST calls from/to the correct DTO's for the REST API, and business logic and coordination between different entities should go in a service class that does not have anything to do with the REST API. In the long term, that makes it easier to make changes in the REST API separate from changes in the business logic.

Some blog posts to read:

https://www.petrikainulainen.net/software-development/design/understanding-spring-web-application-architecture-the-classic-way/

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Then about the decision to use interfaces or not. The main advantages of using interfaces used to be that it allowed better testing and avoided coupling modules too close. But since 2010, there has been a lot of discussion whether it's worth the overhead. Maybe start reading the discussion underneath Adam Bien's original post:

https://www.adam-bien.com/roller/abien/entry/service_s_new_serviceimpl_why

huangapple
  • 本文由 发表于 2020年9月2日 16:38:08
  • 转载请务必保留本文链接:https://go.coder-hub.com/63701759.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定