首次开发REST应用程序，并且之前没有关于Spring Framework的知识。我开发的几乎所有Web应用程序都是PHP（Laravel），C＃（ASP.NET和MVC）或Python（Django）。
当主题是设计模式时，我真的很困惑。
使用https://spring.io/guides（https://spring.io/guides/tutorials/bookmarks/）上提供的指南，我看到要使用的设计模式：
实体，存储库，服务和控制器（RestController），如：
当用户请求/user/{id}时（仅示例），控制器要求服务返回用户，因此，服务询问存储库，返回实体，然后服务传递此实体到控制器（至少在本例中）;
request = Controller -> Service -> Repository -> Entity
response = Repository return Entity -> Service -> Controller
第一件事：
这是对的吗？我知道这是有效的，但这是一种常见的做法（或者至少是一种最佳做法＆＃34;）？
对我来说，似乎没有把Entity（如果此实体是数据库中对象的确切表示）传递给controller。
假设我的实体有密码属性。我已将密码传递给controller。当然，我可以＆＃34;隐藏＆＃34;返回service之前controller上的密码，但controller将收到带有密码属性的entity。
现在，正好相反。假设我想创建一个新用户（Entity），并且在我的数据库中，我有一个expirationDate的属性，该属性是根据注册日期自动计算的。我的Entity陈述必须具有expirationDate属性，但在帖子中，我不需要（我不应该）将任何值传递给此属性。
＆＃34;最佳实践＆＃34;在这种情况下？在C＃/ MVC / ASP.NET中，通常我为这些案例使用了一个新的实体（又名ViewModel）。
查看http://www.robertomarchetto.com/java_rest_api_best_practices_spring_boot，我看到了另一种设计模式，并且对于每种类型的响应（例如Entity和{{}显示存在DTO（或UserResponseDto） 1}}在我的例子中 - DAO与存储库相同？）。
那么，在我的例子中使用这种模式是否正确？
UserRegistrationDto答案 0 :(得分：1)
服务
返回类型：引入transfer object，仅保存控制器所需的数据。
参数类型：引入仅包含服务所需的数据的transfer object。
我在我的博客中总结了我对您可能感兴趣的服务层设计的看法：