Управление тем, какие свойства сериализуются через сервисную ссылку - PullRequest
0 голосов
/ 03 марта 2010

У нас есть сервисная ссылка, которая указывает на сервис WCF, он действует как прокси для нашего уровня модели, где обрабатывается наша логика доступа к данным. Под капотом мы используем Linq2Sql в качестве ORM для облегчения связи с базой данных.

Мы используем сгенерированные классы в качестве уровня доступа к данным, но возвращаемое значение на самом деле является тупыми объектами DTO, которые являются ничем иным, как POCO. Я хотел бы сделать две вещи)

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

2) Я знаю, что Linq2Sql на самом деле украшает все сгенерированные классы, но я не хочу, чтобы эти классы проходили через ссылку на службу.

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

Мысли

Ответы [ 2 ]

0 голосов
/ 04 марта 2010

Вы хотели бы, чтобы DTO проходили через границы ваших служб, абстрагированные от объектов Linq to SQL, правильно?

Если это так, то я бы порекомендовал определить ваш DTO (если у вас много объектов, напишите или найдете несколько хороших шаблонов T4), а затем использовать AutoMapper для перехода между вашими DTO и Linq to SQL.

0 голосов
/ 03 марта 2010

Итак, я выяснил это. В основном, когда вы создаете ссылку на службу, только те типы, которые используются каким-либо образом, сериализуются. По умолчанию, если DataContract отсутствует, все сериализуется.

Если присутствует DataContract, он будет искать оформленные свойства DataMember и сериализовать только их. Tricky

...