聊聊Dto 和 Poco（或 Pojo）有什么區別，你知道嗎？
本文轉載自微信公眾號「DotNET技術圈」，作者Ardalis Steve 。轉載本文請聯系DotNET技術圈公眾號。
在討論 .NET 和 C# 中的軟件開發時經常出現的兩個術語是 DTO 和 POCO。一些開發人員交替使用這些術語。那么，DTO 和 POCO 之間有什么區別?首先，讓我們定義每個術語。
數據傳輸對象 (DTO)
DTO 是“數據傳輸對象”。它是一個目的是傳輸數據的對象。根據定義，DTO 應該只包含數據，而不是邏輯或行為。如果 DTO 包含邏輯，則它不是 DTO。但是等等，什么是“邏輯”或“行為”?
通常，邏輯和行為是指類型上的方法。在 C# 中，DTO 應該只有屬性，并且這些屬性應該只獲取和設置數據，而不是驗證數據或對其執行其他操作。
屬性和數據注釋呢?
將元數據添加到 DTO 以使其支持模型驗證或類似目的并不罕見。這些屬性不會向 DTO 本身添加任何行為，而是促進系統中其他地方的行為。因此，它們不會違反 DTO 不應包含任何行為的“規則”。
ViewModel、API 模型等呢?
DTO 一詞非常含糊。它只是說一個對象只包含數據，而不是行為。它沒有說明其預期用途。在許多架構中，DTO 可以充當多種角色。例如，在大多數具有支持綁定到數據類型的視圖的 MVC 架構中，DTO 用于將數據傳遞和綁定到視圖。這些 DTO 通常稱為 ViewModel，理想情況下它們應該沒有行為，只有按照 View 期望的格式設置數據。因此，在這種情況下，ViewModel 是一種特定類型的 DTO。但是，要小心。然后你不能得出所有 ViewModel 都是 DTO 的結論，因為在MVVM 架構中[1]ViewModel 通常包含大量行為。因此，在做出任何廣泛假設之前考慮上下文非常重要。即使在 MVC 應用程序中，有時邏輯也會添加到 ViewModel 中，這樣它們就不再是 DTO。
DTO 和 ViewModels
只要可能，請根據其預期用途命名您的 DTO。命名一個類FooDTO并沒有說明在應用程序的體系結構中應該如何或在何處使用該類型。相反，更喜歡像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; }
- }
封裝和數據傳輸對象
封裝是面向對象設計的重要原則。但它不適用于 DTO。封裝用于防止類的協作者過于依賴有關類如何執行其操作或存儲其數據的特定實現細節。由于 DTO 沒有操作或行為，并且應該沒有隱藏狀態，因此它們不需要封裝。不要通過使用私有 setter 或試圖讓你的 DTO 表現得像不可變的值對象，從而使你的生活變得更艱難。您的 DTO 應該易于創建、易于編寫和易于閱讀。他們應該支持序列化而不需要任何自定義工作來支持它。
字段或屬性
既然 DTO 不關心封裝，為什么要使用屬性呢?為什么不只使用字段?您可以使用任何一種，但某些序列化框架僅適用于屬性。我通常使用屬性，因為這是 C# 中的約定，但是如果您更喜歡公共字段或有為什么它們更可取的設計原因，您當然可以使用它們。無論您選擇哪種方式，我都會嘗試在您的應用程序中使用字段或屬性時保持一致。有利弊的一些討論在這里[3]。
不變性和記錄類型
不變性在軟件開發中有很多好處，并且在 DTO 中也是一個有用的特性。Jimmy Bogard 寫過關于嘗試在 DTO 中實現不變性的文章[4]，而Mark Seeman[5]在對該文章的評論中(以及在上面的堆棧溢出問題中)采用了相反的方法。就我個人而言，我通常不會將 DTO 構建為不可變的，正如您從上面顯示的示例中看到的那樣。不過，這可能會隨著C# 9 及其引入的記錄類型而改變[6]。順便說一下，您可能會看到的另一個首字母縮寫詞是數據傳輸記錄或 DTR。這是使用 C# 9 定義 DTR 的一種方法：
- public record ProductDTO(int Id, string Name, string Description);
當使用記錄類型和上述位置聲明時，會為您生成一個構造函數，其順序與聲明相同。因此，您將使用以下語法創建此 DTR：
- var dto = new ProductDTO(1, "devBetter Membership", "A one-year subscription to devBetter.com");
或者，您可以以更傳統的方式定義屬性并在構造函數中設置它們。另一個新特性是 init-only 屬性，它支持在創建時初始化，但在其他方面是只讀的，保持記錄不可變。一個例子：
- public record ProductDTO
- {
- public int Id { get; init; }
- public string Name { get; init; }
- }
- // usage
- var dto = new ProductDTO { Id = 1, Name = "some name" };
C# 記錄類型在使用位置聲明時無需任何特殊努力即可支持序列化。如果您創建自己的自定義構造函數，則可能需要向序列化程序提供一些提示。隨著 C# 9、.NET 5 和記錄類型越來越流行，我希望能經常將它們用于 DTR。
普通舊 CLR 對象或普通舊 C# 對象 (POCO)
一個普通的舊 CLR/C# 對象是一個 POCO。Java 有普通的舊 Java 對象，或 POJO。你真的可以將這些統稱為“Plain Old Objects”，但我猜有人不喜歡產生的首字母縮略詞。那么，一個對象“老舊”是什么意思呢?基本上，它不依賴于特定的框架或庫來運行。一個普通的舊對象可以在您的應用程序或測試中的任何地方實例化，并且不需要涉及特定的數據庫或第三方框架來運行。
通過展示反例來演示 POCO 是最簡單的。以下類依賴于一些引用數據庫的靜態方法，這使得該類完全依賴于數據庫的存在才能發揮作用。它還繼承自(組成的)第三方持久性框架中定義的類型。
- 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這樣你就可以調用它的方法。并且您的測試立即失敗，因為您尚未為DataHelpers.LoadFromDatabase要使用的方法配置連接字符串。這是Active Record 模式的[7]一個例子，它可以使單元測試變得更加困難。此類不是Persistence Ignorant (PI)，[8]因為它的持久性直接融入到類本身中，并且該類需要從與持久性相關的基類繼承。POCO 的一個特點是它們往往對持久性一無所知，或者至少比 Active Record 等替代方法更是如此。
一個示例 POCO
下面是一個產品的普通舊 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，因為它不依賴第三方的行為框架，尤其是持久化行為。它不需要基類，尤其是另一個庫中的基類。它與靜態助手沒有任何緊密耦合。它可以在任何地方輕松實例化。它比前面的示例更不了解持久性，但它并非完全不了解持久性，因為它有一個無用的私有構造函數聲明。正如您從評論中看到的那樣，私有無參數構造函數之所以存在，是因為實體框架在從持久性讀取類時需要它來實例化類。
為了論證起見，假設這兩個Product類都包含除了顯示的構造函數和屬性之外的具有行為的方法。這些可以在應用程序中用作DDD 實體[9]，對系統內產品的狀態和行為進行建模。
POCO 和 DTO
好的，所以我們已經看到 DTO 只是一個數據傳輸對象，而 POCO 是一個普通的舊 C#(或 CLR)對象。但是它們之間的關系是什么，為什么開發人員經常混淆這兩個術語?除了首字母縮略詞的相似性之外，最大的因素可能是所有 DTO 都是(或應該是)POCO。
請記住，DTO 的唯一目的是盡可能簡單地傳輸數據。它們應該易于創建、閱讀和編寫。它們對第三方框架中定義的特殊基類的任何依賴或將它們與某些行為緊密耦合的靜態調用都會破壞使類成為 DTO 的規則。為了成為 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 中實現不變性的文章: 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
