DTO服務實現中的核心數據是什么

這篇文章將為大家詳細講解有關DTO服務實現中的核心數據是什么，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

 在一個Web服務的實現中，我們常常需要訪問數據庫，并將從數據庫中所取得的數據顯示在用戶頁面中。這樣做的一個問題是：用于在用戶頁面上展示的數據和從數據庫中取得的數據常常具有較大區別。在這種情況下，我們常常需要向服務端發送多個請求才能將用于在頁面中展示的數據湊齊。

　　一個解決該問題的方法就是根據不同需求使用不同的數據表現形式。在一個服務實現中較為常見的數據表現形式有MO（Model Object，在有些上下文中也被稱為VO，Value Object）和DTO（Data Transfer Object）。MO用來表示從數據庫中讀取的數據，而DTO則用來表示在網絡上所傳輸的數據。

　　我們將討論如何在一個Web服務的實現中使用DTO及MO，并會對其它一些相關數據表現形式，如View Model等進行簡單地介紹。

Why DTO?

　　無論是桌面應用還是長沙做網站公司的Web服務，其內部的數據表現都是非常重要的。在一個初學者了解一個系統的時候，其首先需要了解整個系統中的各個組件的作用，然后再了解系統中的Workflow，即在執行業務邏輯時各個組件是如何協同工作的。在了解了這兩部分之后，該初學者需要做的事情就是詳細地梳理一遍數據是如何在整個系統中流動的，即是整理并理解數據流（Dataflow）的過程。而在真正理解了數據流后，該初學者才具有了在系統中開發的能力。

　　整理數據流的過程是一個逐步細化的過程：從鑒別數據結構到該數據結構中的每個屬性到底是如何使用的。在整個數據流中，任何一個屬性值的改變都可能會導致數據的處理方式發生變化。

　　在整理數據流的時候我們要做什么樣的事情呢？首先我們需要鑒別出到底哪些數據會在各個組件之間進行傳送，在傳送過程中進行了什么樣的轉化，這些數據是如何構建出來的，又由它構建了哪些數據，最終這些數據是否被持久化到了本地存儲中等等。

　　而在整理數據流的過程中，數據的轉化常常是最難理解的部分。一個數據類型的定義常常與其運行環境有關。例如在一個電子商務網站中，一個表示商品的類Product可能包含了該商品的所有信息：商品的名稱，品牌，詳細介紹，價格等。在用戶使用電腦瀏覽器瀏覽的時候，這些信息都將被顯示在頁面上。但是在用戶使用手機進行瀏覽時，我們就需要考慮如何為這些手機用戶節省流量的問題。一種節省用戶手機流量的方法就是首先顯示商品的簡略信息，并在用戶決定查看商品的詳細介紹時再從服務端下載商品的詳細信息。在這種情況下，包含商品所有信息的類Product將不再是適合傳輸的數據結構。

　　而問題不僅僅出在需要將數據結構拆分的情況下，更可能出現在數據合并的情況中。例如網頁的UE為了提高用戶體驗，要求在產品頁面中直接將該商品品牌的詳細信息顯示在頁面中。在這種情況下，我們就需要在表示商品的類Product中添加一個記錄該商品品牌的域brand。但是在數據庫中，表示商品的類Product可能僅僅記錄了商品品牌的ID。因此在業務邏輯中，我們就需要將Product和其對應的Brand合并在一起。

　　甚至說，我們可以將事情弄得更復雜一些：

我們展示了數據在一個系統中可能存在的多種不同表現形式。在圖片的中央位置的是一個服務器，多種客戶端都將從它那里獲得產品信息。就像前面所說，為了節省客戶端的流量，服務端向移動客戶端所發送的數據將是產品信息在服務端中的簡略版本。而在一個瀏覽器訪問該產品的時候，表示商品品牌的信息將內嵌在產品信息之中，以提供更好的用戶體驗。除了與客戶端通訊，服務端之間也可能產生信息的交換。在該交換過程中，表示產品的Product以及表示品牌的Brand則彼此獨立地在服務端之間傳遞。而就一個運行在遠端的Agent而言，其可能僅僅需要一個Product的ID來監控產品在生產制作方面的狀態。

　　而這一切數據都應當從系統的數據庫中得到。數據庫中的數據不可能同時存儲并維護這一系列數據結構，因此在一個復雜的系統中，數據庫中的數據表示與系統中所傳輸的數據之間常常是不同的數據結構。常見的情況則是將其分為兩類：一類用來訪問數據庫，在系統中表現數據庫中所記錄的數據，叫MO，即Model Object；另一類用來在網絡中傳輸，叫DTO，即Data Transfer Object。

服務中的DTO和MO

　　在了解了我們為什么需要DTO和MO等數據的不同表示之后，就讓我們來看看這些數據表示在一個Web服務中是如何工作的。

　　先讓我們從最簡單的Web服務分層開始說起。一個最簡單的Web服務主要分為數據訪問層（DAL），業務邏輯層以及表現層三個部分。其中表現層是運行在客戶端的，而其它兩個層次則運行在服務端。當數據從DAL層讀取出來的時候，其所記錄的數據與數據庫中所記錄的數據是一致的，因此它們就是我們這篇文章中討論的MO。而在傳輸給客戶端的時候，這些數據可能會和MO不同，因此其為DTO：

現在就讓我們放大一下數據訪問層，來看看數據訪問層中MO所在的位置：

首先要強調的是，實現數據訪問層的方式有很多種，而上圖所展示的僅僅是一種基于Repository模式的實現。通過Repository來實現DAL是一種最為常見的數據訪問層實現方式。就像上圖所展示的那樣，在一個基于Repository模式的實現中，數據訪問層將擁有一系列Repository實例。這些Repository實例依賴于系統所使用的ORM來將數據庫中的數據轉化為Java類實例。這些Java類實例實際上就是在該數據訪問層所提供給業務邏輯層的MO。

　　而DTO則用于在服務與客戶之間以及服務和服務之間進行數據的傳遞。在這些傳遞過程中，對DTO的需求可能是多種多樣的：Product這種類型的DTO在服務端和客戶端以及服務端之間進行交互的過程。在該流程中，所需要傳遞的DTO并不相同：在使用瀏覽器讀取和保存有關Product的信息時，兩者的數據表現形式可能會有一些細微的差別。而在保存完畢后，服務可能會將新的Product作為負載來向其它服務器發送請求，而此時所使用的Product的表示又可能與前兩種略有差別。如果為這些細微的差別定義很多不同的DTO，那么系統對數據的管理可能會遇到一系列麻煩。例如在一個復雜的系統中，DTO可能會按照下面的方式在系統中流轉：

　　在上圖中，我們展示了一個DTO在依次流轉過多個服務的情況。如果在DTO依次傳遞的過程中使用了不同的DTO表示，那么一個服務所需要的DTO可能和另一個服務中所擁有的DTO并不匹配。這便是DTO反過來會影響到架構設計的一個最簡單的例子，卻也是DTO管理中最常見的問題，那就是DTO的表現形式過多。如果為所有的不同需求都創建一個DTO，那么一個概念所對應的DTO可能多達5，6種，非常難于管理。這種管理上的困難常常存在于如何指定某個服務所需要使用的DTO種類，以及在更改DTO時需要同時修改一系列DTO的情況中。

　　為了防止DTO由于不同的需求而衍生出過多的種類，服務實現中常常允許DTO中的數據包含一些冗余。

逐步添加你的DTO

　　那么我們該如何向系統中添加DTO呢？答案是，根據情況決定。在項目的一開始，數據庫中所存儲的數據與頁面所需要顯示的數據常常是一致的，因此在這種情況下，我們并不需要DTO的幫助。而在所需要的數據和數據庫所記錄的數據不再一樣的時候，我們就需要考慮是否需要在項目中添加DTO了。這時軟件開發人員就需要問自己：這種所需要的數據與數據庫中的數據不一致的情況是否常常出現？如果答案是“是”，那么我們就需要開始著手準備添加對DTO的支持。

　　在系統中添加DTO主要有以下幾部分工作需要完成：

1. 添加DTO類。

2. 添加從MO到DTO的轉化邏輯。

3. 將原本對MO的使用轉換為對DTO的使用。

　　相信讀者最先注意到的就是第三點。可以想象到的是，如果將整個系統的MO替換成DTO，那么它的影響面將會非常大，而且非常容易出錯。因此在一個大型項目中，我們常常需要預先判斷DTO的必要性，進而盡早地添加DTO。

　　讓我們回過頭來看看第一個任務應該如何完成。在一個系統中，DTO常常用來傳輸數據，因此其自身往往不帶有任何邏輯。這也便是這些DTO常常被定義成JavaBean的原因。以JavaBean的形式來定義DTO帶來了一個巨大的好處，那就是很多第三方類庫都提供了生成JavaBean的功能。在這種情況下，軟件開發人員只需要通過一系列描述性語言來描述這些DTO即可。這其中最常用的便是JAXB。

關于DTO服務實現中的核心數據是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。