wcf:属性与成员的datamember属性

一般来说,您应该倾向于在属性上应用datamember属性,而不是在私有字段上。将该属性应用于字段的唯一原因是该属性是只读的(即它没有setter)。

只要你使用 Name 标记,无论使用字段还是属性,合同都是相同的。

[DataMember(Name="SomeValue")]
private int m_SomeValue;

但是,访问私有成员可能存在一些权限问题,特别是在Silverlight和CF上-在这种情况下,我建议将公共属性用作数据成员。实际上,我倾向于 总是 除非我有充分的理由…

您可能希望将字段而不是属性标记为datamember是有充分理由的。

请检查此项以了解更多详细信息: http://blog.walteralmeida.com/2010/05/wcf-and-datacontract-serialization-internals-and-tips-.html

顺便说一句:ContractSerializers将序列化任何具有dataMemberAttribute的私有字段 仅当在完全信任环境中运行时 . 不在部分信任中工作(请检查上面列出的日志以获得解决方案)

此决定取决于WCF服务的使用:

1. 您拥有共享同一域模型的.NET系统所使用的内部服务。
2. 不共享同一域模型的不同平台使用的外部服务。

案例1。

序列化-是持久化对象状态的过程。C中对象的状态由其数据字段表示。

C中的属性本质上是操作对象状态的方法。使用它们可能导致反序列化的对象状态不同,因为属性的设置顺序可能会影响其最终数据状态。其他因素也可能导致不正确的状态反序列化,例如,方法(属性集)依赖于一些正在更改的上下文,如当前日期时间。

你可以说封装怎么样?我不希望我的对象处于无效状态,我必须进行验证检查、对象图完整性检查等。是的,您应该这样做,所以我们将datamember属性放在props上?不。

这里的问题是很多人混合了两种不同的东西,DTO(数据传输对象,WCF契约)和域实体。您需要的是确保接收的数据与发送的数据完全相同,然后确保可以从此数据构造有效的域实体。实现这一点的最佳方法是为DTO使用单独的类,并从中构造域实体。

但是大多数程序员都懒惰,他们喜欢用datamemeber属性简单地修饰域实体。在这种情况下,决策域或属性取决于验证逻辑所在的位置,如果验证逻辑隐藏在set方法中,则必须使用属性,如果它是扩展的,则应使用字段,并在期望之后验证域实体。

我认为同样的规则也适用于任何序列化过程,比如数据库持久性。

另外,我想说的是,Silverlight不能序列化/反序列化私有字段,因为您不能使用反射从外部访问它们,您必须将它们设为私有并使用InternalsVisibleToAttribute。

案例2。

这很难。这里主要关注的是互操作性。在这种情况下,99.9%的用户将有单独的DTO类,并且很可能有许多不同版本的DTO类来支持旧客户机。你把datamembers attribs放在哪里并不重要,因为你使用的是dto。我不会费心解释这个场景,因为在如此大规模的系统上工作的开发人员通常都很有经验,而且他们也不费心阅读。

理论上,只要你 m_SomeValue 总是等于 SomeValue (就像一个简单的getter/setter),什么都没有。而不是由wcf公开的变量的名称。(显然,如果你在 m_ 变量,那么您的代理类也将具有相同的 My 姓名。无论您使用公共/受保护/内部/私有字段还是属性,代理类都将生成公共属性。

但是,如果在访问器中有任何特殊的逻辑,可以修改返回的值( ToUpper() 例如,如果使用一个字符串,那么您将返回一个不同的值。

就我个人而言,我只会使用该属性,并将成员变量全部删除。即

[DataMember]
public int SomeValue
{ get; set; }

属性将在幕后莫名其妙地创建成员变量。

如果在private int m ou somevalue上添加[datamember],则此成员不能序列化,因此必须将其添加到public int somevalue上。

[DataMember]  
private int m_SomeValue;

public int SomeValue {
  get {...}
  set {...}
}

如果通过wcf使用,则上述代码在客户端中无法获取值。