WCF - несколько сервисных контрактов, использующих одни и те же контракты данных

Вы можете создать отдельные DTO для каждой службы, но ваш случай на самом деле будет идеальным для шаблона декоратора:

[DataContract]
public class UserForService1 : User
{
     private User mUser;
     public UserForService1(User u)
     {
         mUser = u;
     }

     //expose only properties you'd like the user of this data contract to see
     [DataMember]
     public string SomeProperty
     {
         get
         {
            //always call into the 'wrapped' object
            return mUser.SomeProperty;
         }
         set
         {
            mUser.SomeProperty = value;
         }
     }
     // etc...
}

и для Service2 аналогичный код, который раскрывает только то, что вам нужно ...

Если они предназначены для представления разных типов пользователей, они должны относиться к разным классам. Я согласен с phoog в комментариях, вы должны унаследовать нужный тип от общего класса User и добавить определенные свойства службы в производные классы.

Почему вы не думаете, что наследование в этом случае было бы хорошо? Если вы предоставите нам более подробную информацию, мы можем попытаться изменить предложения в соответствии с вашей реальной проблемой.

Как предлагается в комментарии, у вас может быть два класса, производных от базового пользователя, а затем с использованием данных Известные типы контрактов, вы можете достичь желаемой цели. См. Следующие ссылки для получения дополнительных примеров.

http://www.freddes.se/2010/05/19/wcf-knghtype-attribute-example/

http://footheory.com/blogs/bennie/archive/2007/07/28/handling-data-contract-object-hierarchies-in-wcf.aspx

Если вы не хотите использовать наследование, например:

[DataContract]
public class User
{
}

[DataContract]
public class Service1User : User
{
  [DataMember] public string PropertyVisibleOnlyForService1{...}
}

[DataContract]
public class Service2User : User
{
  [DataMember] public string PropertyVisibleOnlyForService2{...}
}

[ServiceContract]
public interface IService1  
{   
   List<Service1User> GetUsers();  // user with 'PropertyVisibleOnlyForService1' inside
}

[ServiceContract]
public interface IService2  
{   
    List<Service2User> GetUsers(); // user with 'PropertyVisibleOnlyForService2' inside 
}

Тогда я не уверен, что ты будешь делать. Ваш вид нарушения принципов объявления типа в этот момент. Подумайте об этом обычным .NET-способом; если вы определите «Пользователь» в своем приложении, то он везде будет одного и того же типа. Некоторые свойства нельзя скрыть от других классов или методов.

WCF также собирается упаковать информацию об этом типе в сгенерированный WSDL, и он будет определять тип User только один раз, поэтому ему необходимо знать, какие свойства существуют.

Теперь, если все, что вас волнует, это фактическое созданное сообщение SOAP, и вам не важен WSDL или то, что увидят любые клиенты, созданные с помощью WSDL, тогда технически вы можете не передавать это свойство в сообщение SOAP. когда он равен нулю, выполнив:

    [DataMember(EmitDefaultValue=false)]

Затем, когда это свойство равно нулю, оно не будет включено в сериализацию. Однако это не имело бы никакого значения, если бы клиент был сгенерирован из WSDL, поскольку его тип User все равно должен был бы содержать оба свойства. Это просто изменит сериализацию, чтобы вместо отправки клиенту что-то вроде:

<User>
  <PropertyVisibleOnlyForService1 nil="true" />
  <PropertyVisibleOnlyForService2>something</PropertyVisibleOnlyForService2>
</User>

вместо этого он отправит:

<User>
  <PropertyVisibleOnlyForService2>something</PropertyVisibleOnlyForService2>
</User>