聊聊Dto 和 Poco（或 Pojo）有什么區(qū)別，你知道嗎？
本文轉(zhuǎn)載自微信公眾號「DotNET技術圈」，作者Ardalis Steve 。轉(zhuǎn)載本文請聯(lián)系DotNET技術圈公眾號。
在討論 .NET 和 C# 中的軟件開發(fā)時經(jīng)常出現(xiàn)的兩個術語是 DTO 和 POCO。一些開發(fā)人員交替使用這些術語。那么，DTO 和 POCO 之間有什么區(qū)別?首先，讓我們定義每個術語。
數(shù)據(jù)傳輸對象 (DTO)
DTO 是“數(shù)據(jù)傳輸對象”。它是一個目的是傳輸數(shù)據(jù)的對象。根據(jù)定義，DTO 應該只包含數(shù)據(jù)，而不是邏輯或行為。如果 DTO 包含邏輯，則它不是 DTO。但是等等，什么是“邏輯”或“行為”?
通常，邏輯和行為是指類型上的方法。在 C# 中，DTO 應該只有屬性，并且這些屬性應該只獲取和設置數(shù)據(jù)，而不是驗證數(shù)據(jù)或?qū)ζ鋱?zhí)行其他操作。
屬性和數(shù)據(jù)注釋呢?
將元數(shù)據(jù)添加到 DTO 以使其支持模型驗證或類似目的并不罕見。這些屬性不會向 DTO 本身添加任何行為，而是促進系統(tǒng)中其他地方的行為。因此，它們不會違反 DTO 不應包含任何行為的“規(guī)則”。
ViewModel、API 模型等呢?
DTO 一詞非常含糊。它只是說一個對象只包含數(shù)據(jù)，而不是行為。它沒有說明其預期用途。在許多架構中，DTO 可以充當多種角色。例如，在大多數(shù)具有支持綁定到數(shù)據(jù)類型的視圖的 MVC 架構中，DTO 用于將數(shù)據(jù)傳遞和綁定到視圖。這些 DTO 通常稱為 ViewModel，理想情況下它們應該沒有行為，只有按照 View 期望的格式設置數(shù)據(jù)。因此，在這種情況下，ViewModel 是一種特定類型的 DTO。但是，要小心。然后你不能得出所有 ViewModel 都是 DTO 的結(jié)論，因為在MVVM 架構中[1]ViewModel 通常包含大量行為。因此，在做出任何廣泛假設之前考慮上下文非常重要。即使在 MVC 應用程序中，有時邏輯也會添加到 ViewModel 中，這樣它們就不再是 DTO。
DTO 和 ViewModels
只要可能，請根據(jù)其預期用途命名您的 DTO。命名一個類FooDTO并沒有說明在應用程序的體系結(jié)構中應該如何或在何處使用該類型。相反，更喜歡像FooViewModel.
C# 中的示例 DTO
下面是 C# 中的示例 DTO 對象：
- public class ProductViewModel
- {
- public int ProductId { get; set; }
- public string Name { get; set; }
- public string Description { get; set; }
- public string ImageUrl { get; set; }
- public decimal UnitPrice { get; set; }
- }
封裝和數(shù)據(jù)傳輸對象
封裝是面向?qū)ο笤O計的重要原則。但它不適用于 DTO。封裝用于防止類的協(xié)作者過于依賴有關類如何執(zhí)行其操作或存儲其數(shù)據(jù)的特定實現(xiàn)細節(jié)。由于 DTO 沒有操作或行為，并且應該沒有隱藏狀態(tài)，因此它們不需要封裝。不要通過使用私有 setter 或試圖讓你的 DTO 表現(xiàn)得像不可變的值對象，從而使你的生活變得更艱難。您的 DTO 應該易于創(chuàng)建、易于編寫和易于閱讀。他們應該支持序列化而不需要任何自定義工作來支持它。
字段或?qū)傩?/h3>
既然 DTO 不關心封裝，為什么要使用屬性呢?為什么不只使用字段?您可以使用任何一種，但某些序列化框架僅適用于屬性。我通常使用屬性，因為這是 C# 中的約定，但是如果您更喜歡公共字段或有為什么它們更可取的設計原因，您當然可以使用它們。無論您選擇哪種方式，我都會嘗試在您的應用程序中使用字段或?qū)傩詴r保持一致。有利弊的一些討論在這里[3]。
不變性和記錄類型
不變性在軟件開發(fā)中有很多好處，并且在 DTO 中也是一個有用的特性。Jimmy Bogard 寫過關于嘗試在 DTO 中實現(xiàn)不變性的文章[4]，而Mark Seeman[5]在對該文章的評論中(以及在上面的堆棧溢出問題中)采用了相反的方法。就我個人而言，我通常不會將 DTO 構建為不可變的，正如您從上面顯示的示例中看到的那樣。不過，這可能會隨著C# 9 及其引入的記錄類型而改變[6]。順便說一下，您可能會看到的另一個首字母縮寫詞是數(shù)據(jù)傳輸記錄或 DTR。這是使用 C# 9 定義 DTR 的一種方法：
- public record ProductDTO(int Id, string Name, string Description);
當使用記錄類型和上述位置聲明時，會為您生成一個構造函數(shù)，其順序與聲明相同。因此，您將使用以下語法創(chuàng)建此 DTR：
- var dto = new ProductDTO(1, "devBetter Membership", "A one-year subscription to devBetter.com");
或者，您可以以更傳統(tǒng)的方式定義屬性并在構造函數(shù)中設置它們。另一個新特性是 init-only 屬性，它支持在創(chuàng)建時初始化，但在其他方面是只讀的，保持記錄不可變。一個例子：
- public record ProductDTO
- {
- public int Id { get; init; }
- public string Name { get; init; }
- }
- // usage
- var dto = new ProductDTO { Id = 1, Name = "some name" };
C# 記錄類型在使用位置聲明時無需任何特殊努力即可支持序列化。如果您創(chuàng)建自己的自定義構造函數(shù)，則可能需要向序列化程序提供一些提示。隨著 C# 9、.NET 5 和記錄類型越來越流行，我希望能經(jīng)常將它們用于 DTR。
普通舊 CLR 對象或普通舊 C# 對象 (POCO)
一個普通的舊 CLR/C# 對象是一個 POCO。Java 有普通的舊 Java 對象，或 POJO。你真的可以將這些統(tǒng)稱為“Plain Old Objects”，但我猜有人不喜歡產(chǎn)生的首字母縮略詞。那么，一個對象“老舊”是什么意思呢?基本上，它不依賴于特定的框架或庫來運行。一個普通的舊對象可以在您的應用程序或測試中的任何地方實例化，并且不需要涉及特定的數(shù)據(jù)庫或第三方框架來運行。
通過展示反例來演示 POCO 是最簡單的。以下類依賴于一些引用數(shù)據(jù)庫的靜態(tài)方法，這使得該類完全依賴于數(shù)據(jù)庫的存在才能發(fā)揮作用。它還繼承自(組成的)第三方持久性框架中定義的類型。
- public class Product : DataObject<Product>
- {
- public Product(int id)
- {
- Id = id;
- InitializeFromDatabase();
- }
- private void InitializeFromDatabase()
- {
- DataHelpers.LoadFromDatabase(this);
- }
- public int Id { get; private set; }
- // other properties and methods
- }
給定這個類定義，假設您想對 上的某個方法進行單元測試Product。你編寫測試，你做的第一件事就是實例化一個新的實例，Product這樣你就可以調(diào)用它的方法。并且您的測試立即失敗，因為您尚未為DataHelpers.LoadFromDatabase要使用的方法配置連接字符串。這是Active Record 模式的[7]一個例子，它可以使單元測試變得更加困難。此類不是Persistence Ignorant (PI)，[8]因為它的持久性直接融入到類本身中，并且該類需要從與持久性相關的基類繼承。POCO 的一個特點是它們往往對持久性一無所知，或者至少比 Active Record 等替代方法更是如此。
一個示例 POCO
下面是一個產(chǎn)品的普通舊 C# 對象示例。
- public class Product
- {
- public Product(int id)
- {
- Id = id;
- }
- private Product()
- {
- // required for EF
- }
- public int Id { get; private set; }
- // other properties and methods
- }
這個Product類是一個 POCO，因為它不依賴第三方的行為框架，尤其是持久化行為。它不需要基類，尤其是另一個庫中的基類。它與靜態(tài)助手沒有任何緊密耦合。它可以在任何地方輕松實例化。它比前面的示例更不了解持久性，但它并非完全不了解持久性，因為它有一個無用的私有構造函數(shù)聲明。正如您從評論中看到的那樣，私有無參數(shù)構造函數(shù)之所以存在，是因為實體框架在從持久性讀取類時需要它來實例化類。
為了論證起見，假設這兩個Product類都包含除了顯示的構造函數(shù)和屬性之外的具有行為的方法。這些可以在應用程序中用作DDD 實體[9]，對系統(tǒng)內(nèi)產(chǎn)品的狀態(tài)和行為進行建模。
POCO 和 DTO
好的，所以我們已經(jīng)看到 DTO 只是一個數(shù)據(jù)傳輸對象，而 POCO 是一個普通的舊 C#(或 CLR)對象。但是它們之間的關系是什么，為什么開發(fā)人員經(jīng)常混淆這兩個術語?除了首字母縮略詞的相似性之外，最大的因素可能是所有 DTO 都是(或應該是)POCO。
請記住，DTO 的唯一目的是盡可能簡單地傳輸數(shù)據(jù)。它們應該易于創(chuàng)建、閱讀和編寫。它們對第三方框架中定義的特殊基類的任何依賴或?qū)⑺鼈兣c某些行為緊密耦合的靜態(tài)調(diào)用都會破壞使類成為 DTO 的規(guī)則。為了成為 DTO，類必須是 POCO。所有 DTO 都是 POCO。
DTO 和 POCO 維恩圖
如果反過來也成立，那么我們可以說這兩個術語是等價的。但我們知道事實并非如此。在前面的代碼示例中，Product使用 Entity Framework 的實體具有私有的 setter 和行為，使其無法成為 DTO。但正如我們所見，它是 POCO 的一個很好的例子。因此，雖然所有 DTO 都是 POCO，但并非所有 POCO 都是 DTO。
References
[1] MVVM 架構中: https://en.wikipedia.org/wiki/Model–view–viewmodel
[2]: https://ardalis.com/static/ef316c071c0c70148e4b0008830eeae1/d52e5/dto-viewmodel-venn.png
[3] 在這里: https://stackoverflow.com/questions/10831314/dtos-properties-or-fields
[4] Jimmy Bogard 寫過關于嘗試在 DTO 中實現(xiàn)不變性的文章: https://jimmybogard.com/immutability-in-dtos/
[5] Mark Seeman: http://blog.ploeh.dk/
[6] C# 9 及其引入的記錄類型而改變: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9
[7] Active Record 模式的: https://www.martinfowler.com/eaaCatalog/activeRecord.html
[8] Persistence Ignorant (PI)，: https://deviq.com/principles/persistence-ignorance
[9] DDD 實體:
https://deviq.com/domain-driven-design/entity : https://ardalis.com/static/517f68e51029cdcba6b2d49ca477b863/7fee5/dto-poco-venn.png
原文鏈接：https://ardalis.com/dto-or-poco/
作者：Ardalis Steve
