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設計模式對其他應用程序的推薦

回答

相關問題