Контракты данных WCF и базовые структуры данных

Мне интересно, что имеет смысл в отношении того, какие объекты предоставлять через службу WCF - следует ли мне добавлять спецификации сериализации WCF к своим бизнес-объектам или мне следует реализовать преобразователь, который сопоставляет мои бизнес-объекты с DataContracts, которые я хочу предоставить через свой WCF услуга?

Сейчас у меня есть сущности на разных уровнях: DataAccess, Business и Contract. У меня есть конвертеры, которые могут отображать объекты из DataAccess в Business и из Business в контракт и наоборот. Их внедрение и поддержка отнимают много времени и довольно утомительны. Каковы лучшие практики в этом отношении?

Если бы я использовал OR / M, такой как NHibernate или Entity Framework, должен ли я открывать объекты из ORM напрямую или абстрагироваться от них так же, как я делаю сейчас?


wcf data-access
person Xerx    schedule 17.09.2008    source источник

Ответы (4)


arrow_upward
12
arrow_downward

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

Шаблоны и методы Microsoft "Service Factory Modeling Edition" реализует это, а также предоставляет инструменты для автоматического создания Business ‹=> Классы конвертера контрактов - это отличная надстройка VS, которая также представляет лучшие практики Microsoft для WCF.

person Guy Starbuck    schedule 17.09.2008

arrow_upward
4
arrow_downward

Обычно я не раскрываю свой бизнес / объекты данных по сети, поскольку мне нравится придерживаться принципа единой ответственности (SRP). Чтобы объяснить, сущности данных были созданы для сопоставления с лежащей в основе реляционной (db) моделью. Итак, единственная причина, по которой они должны «измениться», - это изменение реляционной модели, вот и все.

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

person Javier Lozano    schedule 17.09.2008

arrow_upward
1
arrow_downward

Просто чтобы добавить к приведенным выше ответам: объект, который предоставляет веб-сервис, называется объектом передачи данных (DTO). Наличие DTO для сопоставления вашего объекта Business Entity (BEO) - это хорошо, потому что он обеспечивает разделение между вашим веб-сервисом и фактической реализацией / логикой, лежащей в основе веб-сервиса.

Наконец, вот как вы можете украсить DTO, чтобы, когда он предоставляется WSDL, имена отражали фактические объекты, которые он представляет (вместо objectNameDTO или что-то подобное).

//Business Entity
class Person
{
   public string Name{ get; set; }
   public int Age{ get; set; }
}


//Data transfer object
[DataContract(Name="Person")] //<-- this is what makes the WSDL look nice and clean
class PersonDTO
{
   [DataMember(Name = "Name", Order = 0)]
   public string Name{ get; set; }
   [DataMember(Name = "Age", Order = 1)]
   public int Age{ get; set; }
}
person Raj Rao    schedule 08.03.2010

arrow_upward
1
arrow_downward

Кое-что также следует учитывать, я согласен с разделением, но обычно это приводит к «переводчикам» или какому-то другому коду для копирования данных из DTO в бизнес-объект. Именно здесь такая библиотека, как AutoMapper (http://automapper.org/), становится НАСТОЯЩЕЙ удобной и устраняет нужно написать слой перевода.

person Erick Brown    schedule 13.08.2012