WPF

[ServiceContract]
public interface IMyInterface
{
  [OperationContract]
  List<int> DoSomething(MyData item);
}

[DataContract]
public class MyData
{
  [DataMember]
  public int DataValue1 { get; set; }
  [DataMember]
  public string Identifier { get; set; }
}

public class ImplementInterface : IMyInterface
{
  public List<int> DoSomething(MyData item)
  {
    return item.DataValue1;
  }
}

[ServiceContract]
public interface X
{
[DataMember]
List<Y>  Data {get;} //Y is a new type

}

[Data Contract]
public class Y
{
[DataMember]
public List<object> Data
{
get;
set;
}
}

[DataContract]
public class Y
{
[DataMember]
public int id {get; set;}

[DataMember]
public string Str {get; set;}

[DataMember]
public Z NewType {get; set;}

[DataMember]
Public List<object> Data {get; set;}
}

[DataContract]
public class Z
{
[DataMember]
public int idz {get; set;}

[DataMember]
public string Strz {get; set;}

}

<big>Attribute 'OperationContract' is not valid on this declaration type. It is only valid on 'method' declarations.</big>

public int MyProperty
{
  [OperationContract]get;
  [OperationContract]set;
}

• If your contract isn't small, a struct doesn't make much sense. If we assume you have non-trivial data, then the stack usage more than outweighs the prevention of heap allocation that structs bring to the table.
• You cannot use default constructors or field initializers with structs, which we use a fair bit.
• Structs tend to make sense when they are used in lots of places. Assuming that they don't form a large part of your architecture, then you aren't going to see much benefit from them.




"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.




My blog | My articles | MoXAML PowerToys | Onyx