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

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

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

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

Ответы

Ответ 1

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

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

Ответ 2

Я, как правило, не раскрываю свои бизнес/данные в сети, так как мне нравится придерживаться принципа единой ответственности (srp). Чтобы объяснить, объекты данных были созданы для сопоставления с базовой реляционной (db) моделью. Поэтому единственная причина, по которой они должны "меняться", - это изменение в реляционной модели, что она.

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

Ответ 3

Просто добавьте следующие ответы: Объект, который предоставляет веб-служба, называется объектом передачи данных (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; }
}

Ответ 4

Что-то, что нужно учитывать, я согласен с разделением, но обычно это приводит к "переводчикам" или некоторому подобному коду для копирования данных из DTO в Business Entity. Именно здесь библиотека, такая как AutoMapper (http://automapper.org/), поставляется в режиме реального времени и устраняет необходимость писать слой перевода.