自從nhibernate與wcf出現以來，.net開發者們就開始向統一的實體模型概念上不斷靠攏。最後的結果就是同乙個類可以作為orm實體、wcf dto以及mvc、mvp與mvvm框架的模型。.net dependency injection的作者mark seemann認為這不見得是件好事。
\u0026#xd;\n
問題的關鍵在於「在邊界處，應用並不是物件導向的」。如你所見，大多數序列化技術都要求public、預設的構造方法以及可寫的屬性。本質上，在設計dto時，這些要求會迫使你打破封裝和資料隱藏的原則。甚至連基本的不變性，如要求欄位不為null/不為空都不可能實現，因為dto會忽略掉一切。mark seemann繼續證明自己的論斷：
\u0026#xd;\n
\u0026#xd;\n
根據這種情況，mark提出了3種觀點：
\u0026#xd;\n
第1\u0026#xd;\n種觀點是堅持已有的觀念。為了消除隔閡，我們必須得開發乙個轉換層，用於將dto轉換為封裝良好的領域物件。這正是書中的示例所採取的方式。然而，我越發覺得這種解決方案並不是最佳的。這會導致可維護性的問題（這也是我寫書時所遇到的問題：當你寫完後，你所知道的要比剛開始動筆時多不少，我並不是說書不好，只是想說它並不完美而已）。
\u0026#xd;\n第2種觀點是不再將資料當作物件，將其看作是它自身所表示的結構化資料。如果我們所用的程式語言有單獨的結構化資料概念就太好了。有趣的是，雖然c#並沒有這個概念，但f#卻有多種方式來建模資料結構而不涉及行為。或許這是更好的資料處理方式，我還要多嘗試幾次才行。
\u0026#xd;\n第3種觀點是使用動態型別。在文章cutting edge: expando objects in c# 4.0中，dino esposito介紹了通過動態方法來使用結構化資料，這可以更快速地自動生成**並向結構化資料提供輕量級的api。這種方法更有前途，它並沒有提供編譯期的反饋，但這只不過是一種安全上的錯覺而已。我們需要通過單元測試來快速獲取反饋，但我們一直都在使用tdd，不是麼？
如果你對物件導向設計與封裝感興趣，那就一定不能錯過名為poka-yoke design: from smell to fragrance的系列文章。
\u0026#xd;\n
檢視英文原文：differing opinions: dtos vs domain objects
DTO與實體物件的區別
1 什麼是dto dto data tansfer object 即資料傳輸物件。之前不明白有些框架中為什麼要專門定義dto來繫結表現層中的資料，為什麼不能直接用實體模型呢，有了dto同時還要維護dto與model之間的對映關係，多麻煩。然後看了這篇文章中的討論部分才恍然大悟。表現層與應用層之間是通...
DDD 領域物件與領域服務
什麼是領域物件 什麼是領域服務 領域物件的行為，與領域服務的行為區別 為什麼把這麼小的點拿出來講，最開始在討論中領域物件與領域服務時，覺得行為放在service entity中區別不大，只是乙個放置位置的問題，並不影響到 的抽象和復用，所以沒有實行。但是最近在推動產品進行ddd業務建模，發現這個問題...
收集 IT 領域倫理與道德的事實或觀點
一些百合網上普遍被認為存在倫理風險的做法 事關千萬網民私人資訊的資訊保安問題 下面是有關報道 是否按照個人意願分配 下面是有關報道 可能出現多種違法事件 下面是有關報道 ai 技術與倫理 這是一篇題為developing a data ethics framework in the age of a...