Реализовать IExtensibleDataObject в базовом классе

В настоящее время у нас есть несколько сервисов WCF, которые предоставляют нашу модель предметной области напрямую через сеть. Другими словами, у нас нет уровня DTO для сопоставления между нашим доменом и уровнями обслуживания. У меня нет другого выбора, кроме как напрямую декорировать объекты домена с помощью [DataContract] и [DataMember]. Я хочу реализовать IExtensibleDataObject для всех наших объектов домена, которые доступны по сети. Кто-нибудь видит что-то неправильное в реализации IExtensibleDataObject в базовом классе? Итак, я бы:

[DataContract]
public EntityBase:IExtensibleDataObject{///IExtensibleDataObject Impl}

[DataContract] 
public Person:EntityBase{}

[DataContract]
public Employee:Person{}

заранее спасибо


person WcfDev    schedule 11.01.2010    source источник
comment
Ваш код должен работать нормально. На самом деле, если вы посмотрите на код, сгенерированный svcutil, вы увидите код, который выглядит точно так же, как ваш. Перейдите по этой ссылке для получения дополнительной информации: msdn.microsoft. com/ru-ru/library/   -  person Kwal    schedule 12.01.2010


Ответы (1)


Спасибо, Мэтт. Думаю, я знаю, что это работает нормально, но мои вопросы больше связаны с дизайном SOA. Я знаю, что в мире объектно-ориентированного программирования это нормально, но поскольку объекты моего домена также служат DTO, я беспокоюсь, что добавление этой цепочки наследования приведет к проблемам в будущем. Кто-нибудь еще реализует IExtensibleDataObject? Если да, реализуете ли вы IExtensibleDataObject во всех своих контрактах данных или в базовом классе?

person Community    schedule 12.01.2010
comment
Приношу извинения, так как неправильно понял, о чем вы спрашивали. С точки зрения чистой SOA нежелательно иметь такой механизм, как IExtensibleDataObject, поскольку он может маскировать вещи с точки зрения контракта. При этом я думаю, что идея была одной из удобных. Вот хороший пост, содержащий как плюсы (сам пост), так и минусы (первый комментарий): bloggingabout.net/blogs/vagif/archive/2009/03/29/ - person Kwal; 15.01.2010