Контракты WCF с данными и совместное использование перечислений

Question

В настоящее время у нас есть служба WCF, которая настроена со своими собственными DataContracts для перечислений. Затем у нас есть слой отображения между перечислениями DataContract и общими перечислениями, доступными на нашем бизнес-уровне. То же самое происходит на стороне клиента - слой отображения между клиентом Enum и контрактом данных Enum

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

что думают люди по этому поводу?

Answer 1

Если вам нужен лучший опыт, текущая настройка звучит довольно разумно - вы можете довольно легко управлять версиями и другими валидациями / сопоставлениями на границе с помощью отдельного слоя DTO.

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

Недостатком является повышенное обслуживание, но оно делает их очень гибкими и избегает любыхнеожиданные проблемы.Например, обычно это не относится к WCF, но классическая ошибка с обычными веб-службами - добавление конструктора не по умолчанию (таким образом, удаляется созданный компилятором конструктор по умолчанию).К сожалению!больше нет веб-сервиса.Существует похожая тема ошибок, вызванных невинно выглядящими изменениями, которых можно избежать, выделяя DTO.

Answer 2

Я бы хотел иметь отдельное перечисление контракта данных на уровне обслуживания, которое сопоставляется с перечислением BL из версии совместимости POV.Это позволит в будущем сохранить те же самые значения перечисления обслуживания и интерпретацию, даже если значения перечисления от BL изменятся.Например, вы можете начать с 4-5 одинаковых значений (0, 1, 2, 3, 4) как на уровне обслуживания, так и на уровне бизнеса.В будущем вы решили изменить бизнес-перечисление на флаговую интерпретацию - поэтому наличие отдельного сервисного перечисления позволит сопоставить эти значения с новыми значениями бизнес-перечисления (надеясь, что такая же интерпретация будет доступна на этом уровне) - для примера 3 теперьполучите 8 в бизнес-перечислении.

Answer 3

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

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

Пожалуйста, поделитесь, если у вас есть лучшее решение.