I have a service contract:

```
[DataContract]
public class Something
{
    [DataMember]
    public MyEnum SomeEnumMember {get;set;}
}

```

Some of our devs are doing this sort of thing:

```
public Something()
{
    SomeEnumMember = MyEnum.SecondEnumValue;
}

```

I am of the opinion that constructor logic does not belong in our service contracts since that code won't work if you use "Add Service Reference..." and are working with proxy classes generated by Visual Studio.

Internally, we are using Castle DynamicProxy as shown [here](http://brandonzeider.me/2011/microsoft-net/building-a-reusable-service-client/). However, I would prefer our devs avoid constructor logic in service contract classes in case we can't use DynamicProxy for some reason.

So: does constructor logic have a place in these classes, or as a matter of best practice should we look at them as more of a DTO and implement them with no behavior?