Должен ли я украшать свои классы / свойства как DataContract / DataMember, когда я использую их в WCF? - PullRequest
Новая
       12

Должен ли я украшать свои классы / свойства как DataContract / DataMember, когда я использую их в WCF?

3 голосов
/ 28 августа 2009

У меня есть фреймворк с объектами и кодом доступа к данным. Эти объекты сопоставляются с базой данных с помощью NHibernate.

Например, мой фреймворк имеет класс Customer и Order: 

public class Customer
{
      private Guid _id;
      private string _name;
      private IList<Order> _orders;

      public properties...
}


public class Order
{
     private Guid _id;
     private string _orderNumber;

     public properties...
}

У меня также есть служба WCF с методом PersistCustomer. Вот так: 

[ServiceContract]
public interface ICustomerService
{

      [OperationContract]
      void PersistCustomer(Customer customer);
}

В этом WCF есть ссылка на мою библиотеку фреймворков.

Я создал клиентское приложение для службы WCF (простое консольное приложение), и оно работает!

Главное, чего я не мог понять: почему это работает без декорирования моих классов в рамках как DataContract и их свойств как DataMembers? И я должен украсить их?

Спасибо

Ответы [ 2 ]

3 голосов
/ 28 августа 2009

Ваши классы отлично сериализуются из-за явной поддержки, добавленной в .NET 3.5 SP1 для простых старых объектов C # (POCO).

Вероятно, это было добавлено по двум причинам:

  • Обратная совместимость со службами ASMX
  • Упрощает начало работы с WCF

Хорошее резюме можно найти в Аароне Сконнарде статья DataContracts без атрибутов (поддержка POCO) в .NET 3.5 SP1 .

Однако, как и в @blowdart, вы должны украсить свои DataContracts, что затем заставит вас использовать DataMember, чтобы это было явным во время сериализации. Рано или поздно вам потребуется изменить DataContract, и вам, вероятно, потребуется поддерживать обратную совместимость с существующими клиентами.

3 голосов
/ 28 августа 2009

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

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

...