我需要創建一些DTO類來將業務對象傳送到WCF。DTO。屬性或字段？
由於這些只是沒有功能的數據包，是否有任何理由我不能僅僅使用字段，或者是否有一些很好的理由將它們正確地公開爲屬性？
//fields
[DataContract]
class CustomerDTO
{
[DataMember] public int Id;
[DataMember] public string Name;
}
//or properties?
[DataContract]
class CustomerDTO
{
[DataMember] public int Id { get; set; }
[DataMember] public string Name { get; set; }
}
由於這些都只是無功能的數據包，沒有任何理由，我不能只是使用領域
有對這裏的公共領域沒有任何有力的論據。但是要意識到，這只是因爲DTO內沒有邏輯（行爲），所以封裝的正常參數不成立。
我仍然會喜歡屬性，但它們在這裏並不是非常必要。
我從來沒有直接暴露領域，大多數公司在其標準禁止這一點。有效地，你完全扔掉封裝。由於它們的屬性幾乎破壞了封裝，所以DTOs是更復雜的東西的貧乏表示。就我個人而言，我會使用它們的屬性。它還可以讓你實現「髒」功能等，如果你需要哪些不是那麼容易，如果你直接調整字段。
屬性的一個問題是，如果屬性具有結構類型，那麼訪問該結構的任何部分將需要製作整個事物的額外臨時副本。暴露結構字段時，這種浪費的複製操作不是必需的。 – supercat
DataMember屬性將與公共字段和屬性一起使用，所以兩者都是可能的。不過，我會建議堅持使用屬性。
特別是，如果您使用StyleCop，那麼您將打破rule SA1401。
此規則存在的原因並不適用於您的情況，但如果您將StyleCop驗證作爲持續集成服務器上的構建的一部分運行，它仍然是維護問題。
如果解決方案將這些DTO放置在特定位置，則可以在此特定規則上爲該位置設置樣式覆蓋。 – Oded
確實，但這仍然是一個需要解決的維護問題。 – devdigital
您可以使用。由於它不會影響性能，因此在使用某些序列化框架或類似的方法時，如果使用屬性來處理公有字段，將會更安全。
注意WCF代理生成將創建在客戶端的DTO的使用公共屬性和他們支持的私人領域，即使你在服務端使用公共領域。如果你不知道這一點，你需要在服務和客戶端之間共享一個DTO庫。
謝謝你們。純粹爲了一致性而使用屬性。 – GazTheDestroyer