Класс WCF DataContract с методами - PullRequest
Новая
       11

Класс WCF DataContract с методами

3 голосов
/ 15 июля 2009

Это скорее вопрос философской / передовой практики, а не техническая проблема.

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

Например: 

[DataContract]
public class LogEntry
{
  [DataMember]
  public string Message { get; set; }
  [DataMember]
  public string Severity { get; set; }

  public string SomeOtherProperty { get; set; }

  ...

  public void WriteToDatabase()
  {
    ...
  }
}

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

Ответы [ 3 ]

3 голосов
/ 25 сентября 2011

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

В вашем примере у вас есть объект, транспорт и способ записи в базу данных в одном классе: 

[DataContract]
public class LogEntry
{
    ...

     public void WriteToDatabase()

Я бы порекомендовал, чтобы ваш интерфейсный код и сериализуемые объекты были отделены от вашего сопротивления. Я бы даже порекомендовал отдельный уровень доступа к базе данных, который не знает уровней и ответственности над уровнями над ним, которые владеют транспортной и бизнес-логикой.

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

Разделение слоев также помогает при тестировании. Возможность протестировать блок кода без всех зависимостей полной системы является ценным. Например, если вы разделяете персистентность вашей базы данных и даже отделяете ее с помощью интерфейса, для модульного тестирования вашей бизнес-логики вы можете заменить персистентность реализацией с подмножеством в памяти.

Одной из проблем становится то, как вы передаете эти объекты в DAL, если он не знает об объектах, которые переносятся. Чтобы обеспечить разделение, я видел типы dll, которые просто содержат эти структуры с декорациями контракта данных, сервисный уровень, которому принадлежит транспорт, и BLL / DAL, которые оба ссылаются на типы dll.

Надеюсь, это поможет.

1 голос
/ 15 июля 2009

Вы, безусловно, можете добавить к типу все, что захотите, потому что в отношении WCF только члены, которые явно указали в качестве DataMembers, являются частью контракта и будут сериализованы таким образом.

Я думаю, что не чистее заключать в контракт посторонних участников, так как это может привести к путанице при использовании типа.

0 голосов
/ 15 июля 2009

На самом деле, это действительно зависит от контекста

под контекстом я имею в виду: Первый контекст управления проектом: денежный бюджет / время / уровень разработчиков / ожидаемое время жизни вашего проекта Тогда контекст WCF: это веб-сервис (wsdl) или передача по именованной трубе

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

Во всех остальных случаях я бы предложил четко отделить код контракта от деталей реализации.

Обратите внимание, что в контексте WCF namedpipe вам может быть интересно реализовать только один раз этот контракт в сборке, совместно используемой как клиентами, так и сервером. В этом случае вы рискуете выставить клиентам подписи сервера.

...