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

Question

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?

Answer 1

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