Дизайн границ данных WCF

Question

это скорее вопрос дизайна:

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

Идея состоит в том, что я действительно не хочу, чтобы ситуация, когда внутренний объект будет открыт для WCFошибка (это только что произошло со мной для внутреннего объекта, даже не помеченного как [DataContract] ), поэтому я подумал о следующем подходе:

1. Design My Сервисные контракты WCF файлы, не имеющие ссылок на пространство имен внутренних типов - это обеспечитмне лучше безопасность.

2. Реализовать переводы между внутренними типами и соответствующими им объектами общедоступного представления в коде реализации службы .

Этоправильный подход?Существуют ли какие-либо известные шаблоны, которые лучше решают вышеуказанные проблемы?

Большое спасибо, Офер

Answer 1

Во-первых, я хотел бы заверить вас, что вполне нормально иметь другую модель в реализации сервиса по сравнению с моделью уровня сервиса. Есть несколько причин, почему это может произойти и / или полезно, две из которых:

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

В моем опыте обе причины верны и обе имеют значение. Вместе со своей командой я часто называю модель, используемую в качестве уровня обслуживания, как «Модель домена уровня обслуживания». Я уверен, что есть и другие, лучшие имена.

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

Кроме того, вместо перемещения данных клиенту службы и обратно в службу вы также можете определить операции с этими данными, которые могут быть выполнены службой. Таким образом, во-первых, вы избежите проблемы.

Удачи!

Answer 2

Сделайте два типа. Дублирующий код - это плохо, да, но ваши внутренние данные и ваш DTO отличаются, и перевод между ними довольно распространен.

Лично я бы сказал, что это почти лучшая практика.

Кроме того, подумайте о своем контракте и о том, нужно ли отправлять весь объект данных или вы можете просто выполнить удаленные команды для него.