我需要创建一些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