Spring设计模式对其他应用程序的推荐

第一次开发一个REST应用程序，并且以前没有关于Spring Framework的知识。几乎所有我开发的Web应用程序都是PHP（Laravel），C＃（ASP.NET和MVC）或Python（Django）。Spring设计模式对其他应用程序的推荐

当主题是设计模式时，我非常困惑。

使用上https://spring.io/guides（https://spring.io/guides/tutorials/bookmarks/）提供的指南，我看到一个设计模式是使用：

实体，库，服务和控制器（RestController），如：

当用户请求/user/{id}（仅举例）时，控制器要求S ervice返回用户，那么，服务问库，具有实体该返回，因此，该服务通此实体到控制器（至少在本例中） ;

request = Controller -> Service -> Repository -> Entity 
response = Repository return Entity -> Service -> Controller

第一件事：

这是正确的？我知道这些作品，但这是一种常见做法（或至少是“最佳做法”）？

对我来说，看起来并不正确通过Entity（如果此实体是数据库中对象的确切表示）到我的controller。

假设我的实体具有密码属性。我将密码传递给我的controller。当然，我可以在回到controller之前“隐藏”service的密码，但controller仍然会收到带有密码属性的entity。

现在，以相反的方式。假设我想创建一个新用户（Entity），并且在我的数据库中，我有一个expirationDate属性，根据注册日期自动计算。我的Entity表示必须具有expirationDate属性，但在发布后，我不需要（也不应该）将任何值传递给此属性。

这种情况下的“最佳实践”是什么？在C＃/ MVC/ASP.NET中，通常我为这些情况使用了一个新实体（又名ViewModel）。

看着http://www.robertomarchetto.com/java_rest_api_best_practices_spring_boot，我看到了另一种设计模式，似乎存在Entity（或DTO）对每个响应的类型（如UserResponseDto和UserRegistrationDto在我的例子 - DAO比库一样？）。

那么，在我的例子中是正确的使用这种模式？

request -> Controller -> Service -> Repository -> Entity (DB representation) 
response -> Repository return a Entity -> Service convert Entity to a DTO -> Controller

来源

2017-08-05 Roberto Correia

对于服务

返回类型：引入transfer object仅认为，控制器需要的数据。
参数类型：引入transfer object仅认为，服务需要的数据。

我summerized我对服务层设计的思想在我的博客，你可能有兴趣

来源

2017-08-05 08:23:30

谢谢！ [使用bean验证简化服务层设计]（https://www.link-intersystems.com/blog/2012/02/05/simplify-service-layer-design-using-bean-validation-jsr-303/）对我来说是新事物！真的有帮助！：d –

Spring设计模式对其他应用程序的推荐

回答

相关问题