使用Hibernate時獲取DTO和實體與服務和DAO的最佳實踐

Question

** 1。服務使用情況：當你看到一個hibernate spring教程時，他們都說對於一個實體（比如我的情況下的用戶），你必須有一個名爲UserRepository的倉庫，其中包含find，findAll，delete等方法。通常，UserRepository擴展了一些基本倉庫接口。

然後你必須添加UserService，它注入一個UserRepository。

a。我必須有一個由UserServiceImpl實現的UserService接口嗎？從我的角度來看，它沒有增加任何價值。我可以讓UserService成爲一個類，並使用Spring的能力來使用GCLIB而不是JDKInterfaces來創建代理。

b。通過複製UserRepository中的每個方法並委派給@Autowired存儲庫，然後添加任何其他商業方法來編寫UserService是否正確？

c。如果我的UserService沒有任何商業方法，它只是委託一切到UserRepository，我可以跳過UserService並直接從REST層訪問UserRepoisitory？

d。假設我也有一個Address實體。用戶在保存時需要一個地址（這是一個強制性的）。 UserService是否可以將UserRepository和AddressRepository注入其中，在那裏建立關係，然後在每個存儲庫上調用save？ （不想使用級聯堅持，我想知道我怎麼會沒有它，因爲在某些情況下，你不能使用級聯）

2. DTO用法：當你想讀取數據，你可以取實體或通過JPQL直接獲取DTO（或Criteria，我更喜歡JPQL）。

a。從我的角度來看，我總是使用DTO而不是實體抓取。這是因爲，我認爲SQL很簡單，如果我必須考慮實體合併，分離，附加等，我錯過了SQL的整個簡​​單性，並且ORM在性能和複雜性方面成爲敵人。因此，當我修改數據時，我總是在讀取數據和實體時使用DTO。你怎麼看？

b。我想返回用戶實體的所有列。有沒有UserDTo可以，或者我誇大，應該只是返回一個用戶實體？我有50％ - 50％。

c。我想部分返回來自用戶的一些列。在這裏，我是75％的DTO和25％的實體。你怎麼看？

d。我想返回一些用戶列和地址列。在這裏，我是DTO的100％（儘管我可以加入獲取地址）。你怎麼看？

親切的問候，

Answer 1

我會回答他們一個接一個：

1.A）是的，這有一定道理。服務層是事務邊界，它是通過一個粗粒度接口將業務邏輯展示給外部世界的地方。不，不是，它不是。UserService定義了業務方法，而不是數據訪問方法。

1.c）我仍然保持服務。

1.d）當然是這樣。您不需要通過實體名稱來調用服務。通過他們所表達的業務邏輯關注來命名它。

2.a）我的規則很簡單：計劃修改時的實體和只讀投影的DTO。

2.b）與2.a相同。

2.c）與2.a相同。 If you need to modify the fetched data later, then use subentities。

2.d）與2.a相同。如果您需要修改數據，請使用實體或子實體。否則，DTO用於只讀投影。