現在我研究了基于JAVA平臺的Spring Boot。
我面臨的一個問題是如何區分 DTO、VO、Entity、Domain 和 Model。
老實說，這一切看起來都太相似了，無法區分。
我已經檢查了一些關于“DTO 和 VO 之間的差異”之類的 stackoverflow 答案。
但是，我仍然想知道它們在使用 Spring Boot 的開發人員方面有何不同。
uj5u.com熱心網友回復：
- 物體 - 是具有 ID 的類。在關系資料庫的情況下，它通常是一個映射到具有一些主鍵的資料庫表的類。
- DTO（資料傳輸物件）- 是一個可以很好地映射您通過網路發送的內容的類。例如，如果您交換 JSON 或 XML 資料，它通常具有足以填充這些請求/回應的欄位。請注意，它可能具有比物體更少或更多的欄位。
- VO（值物件）是一個類值。例如，您可以創建像 Grams 或 Money 這樣的類——它將包含一些原語（例如一些
double值），并且可以使用這些原語比較值物件。他們沒有資料庫 ID。它們有助于用與我們特定領域相關的更多面向物件的類替換原語。 - 域模型包含所有物體和值物件。以及其他一些型別的類，具體取決于您使用的分類。
為了熟悉這些，您應該閱讀：
- Fowler 的企業應用程式模式。提到價值物件和領域模型。
- Eric Evans 的領域驅動設計。提到物體、價值物件和領域模型。
- 并且可能熟悉 Java EE 設計模式。他們提到了 DTO。但這些都是寫得很糟糕的文章（如果它們仍然可以在互聯網上找到的話）。令人困惑的是，他們還有價值物件，它的定義與 DTO 非常相似，但沒有人使用 VO 的定義。
uj5u.com熱心網友回復：
這些只是文字，對于它們的確切含義沒有普遍的共識。
它們在不同的專案中具有不同的含義，而加入專案的一部分是學習那些特定于專案的定義。
此外，這些詞的定義 - 重疊，因為它們不是“一口氣”發明的，而是傳統上用于有影響力的書籍、博客等/
例如：
- DTO 是 2000 年代初期的一個概念；那時，官方的 J2EE Java 強制使用（早已被遺忘和棄用的）“物體 EJB”與資料庫進行互動。事實證明，使用它們的最佳模式是創建額外的“傳輸物件”，僅用于管理 DAO 和“會話 ejb”（現在稱為“服務”）之間的通信。然后 Hibernate 出現了，帶來了“透明持久性”和“我們不需要單獨的 DTO，我們可以只使用 POJO 物體”的想法。不久之后，J, PA 誕生了。在一般情況下，“DTO”變成了“物體”，并且 DTO 這個名稱被重新用于“任何型別的資料，這些資料被打包用于與外部系統互動”。
- VO 常用于“只讀型別的 DTO”。但有時，在領域驅動設計中，人們用這個術語來對比領域物件：“物體”是可以改變并保持“不變”的物件，而“價值物件”是不能改變的東西，因為它們會“變成別的東西”。例如，一輛車可以改變它的顏色，它仍然是“同一輛車”。另一方面，日期“1977-04-05”不能“變異”為“2011-04-05”，因為它只會變成其他日期。
要點：
- 永遠不需要知道單詞的抽象定義。您將始終需要在背景關系中理解它們；
- 不要相信（也不相信）那些試圖告訴你關于這些定義的“絕對真理”的人。你總是會發現同樣聰明的人聲稱完全不同的東西。
- 理解軟體架構沒有王道，沒有“簡要總結”。它更像是哲學或歷史，而不是工程學。
uj5u.com熱心網友回復：
概括
- 一個物體：
是一個輕量級的持久域物件。通常，一個物體代表關系資料庫中的一個表，每個物體實體對應于該表中的一行。物體的主要編程工件是物體類，盡管物體可以使用幫助類。
DTO（資料傳輸物件）：
是用于在層和層之間傳輸資料的容器。當您使用遠程介面時，每次呼叫都很昂貴，應該減少呼叫次數。解決方案是創建一個資料傳輸物件，該物件可以保存呼叫的所有資料。它需要可序列化才能通過連接。通常在服務器端使用匯編程式在 DTO 和任何域物件之間傳輸資料。它通常只不過是一堆欄位以及它們的 getter 和 setter。
- VO-A 值物件：
表示自己是一組固定的資料，類似于Java enum.值物件的標識基于它們的狀態而不是它們的物件標識，并且是不可變的。一個真實的例子是 Color.RED、Color.BLUE、SEX.FEMALE 等。
域模型：
包含所有物體和值物件。以及其他一些型別的類，具體取決于您使用的分類。Model：
定義模型屬性的持有者，主要用于向模型添加屬性。ModelMap：
是 Model 的擴展，能夠將屬性存盤在 map 和鏈方法呼叫中。ModelAndView：
是模型和視圖的持有者；它允許在一個回傳值中回傳模型和視圖。Model、ModelMap 和 ModelAndView 用于在 Spring MVC 應用程式中定義模型。
DAO（資料訪問物件）或存盤庫：
資料訪問物件抽象并封裝了對資料源的所有訪問。DAO 管理與資料源的連接以獲取和存盤資料。DAO 實作了處理資料源所需的訪問機制。資料源可以是像 RDBMS 這樣的持久存盤，也可以是通過 REST 或 SOAP 訪問的業務服務。
DAO 抽象了服務物件的底層資料訪問實作，以實作對資料源的透明訪問。該服務還將資料加載和存盤操作委托給 DAO。
服務： A
Service Layer從連接客戶端層的角度定義了應用程式的邊界及其可用操作集。它封裝了應用程式的業務邏輯，控制事務并在其操作的實作中協調回應。
盡管將業務邏輯放在這里是在 EJB 1.x 和 2.x 時代引入的一種反模式。最好將與業務相關的功能放入域模型中。閱讀貧血與豐富模型：貧血架構 - 測驗的敵人
圖層
在了解 Spring Boot 架構之前，您必須了解其中存在的不同層和類。Spring Boot中有四層如下：
表示層：
表示層處理 HTTP 請求，將 JSON 引數轉換為物件，并對請求進行身份驗證并將其傳遞給業務層。簡而言之，它由視圖即前端部分組成。業務層：
業務層處理所有業務邏輯。它由服務類組成，并使用資料訪問層提供的服務。它還執行授權和驗證。持久性和資料庫層：
持久性層包含所有存盤邏輯，并將業務物件從資料庫行轉換為資料庫行。這也是執行 CRUD（創建、檢索、更新、洗掉）操作的地方。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/466493.html