将Structs与WCF服务一起使用
有没有关于使用结构作为WCF服务的返回类型的官方建议？
我目前正在与我没有写的服务进行互动，并发现自己受到启发，要求查看我的烦恼是否合理。
我过去总是使用类 – 可能部分是因为这是样本总是显示的，但正如我现在想的那样，出于其他“直观”的原因：
-
我通过定义一个单独的项目开始了契约风格，这个项目的接口代表了服务来回传递的类型。
-
我使用LINQ很多，因此对于可空性的测试是隐含的引用类型，而对于结构和其他值类型，我总是需要标记为可空。
虽然我承认它比我脑子里的项目符号列表更直观，但是有些东西会马上来找我。 我想问这个问题，因为我正在处理一个返回结构的服务，并且在处理返回值时必须写：
var foo = Bar.Value.MyField; 代替
var foo = Bar.Value;
如果你可以创建一个结构并在其上放置一个[DataContract]属性 – 继续使用它！ 对于WCF，这没有什么区别–WCF只要求使用标记有DataContract属性的类或结构，并且要包含在序列化消息中的所有字段都要用[DataMember]属性标记。
如果您检查DataContractAttribute上的MSDN文档，它表明您也可以在结构上使用它：
[AttributeUsageAttribute(AttributeTargets.Class| AttributeTargets.Struct|AttributeTargets.Enum, Inherited = false, AllowMultiple = false)] public sealed class DataContractAttribute : Attribute
更新：至于何时使用结构而不是类（通常在.NET中），请在此处查看此SO问题：
我什么时候应该使用结构而不是类？
但是，由于WCF实际上是关于消息传递（即您的客户端进行方法调用，该调用及其参数将转换为序列化消息，该消息通过线路发送，然后在另一端重新组装并转回方法我没有看到使用struct任何令人信服的理由。
一般.NET的所有好处并不真正适用于WCF的SOA世界，我会说（你不会传递类或结构实例 – 见上文）。