2010-07-15 1 views
0

Мне нужно обернуть устаревший API сборки сборки (набор классов и интерфейсов) с помощью службы WCF. Сервис рассматривается как прокси-сервер, который делегирует вызовы существующим классам практически без дополнительной работы.WCF: обертывание устаревшего вопроса API

Итак, я добавил [ServiceContract] interface, который предоставляет методы, которые имеют дело с существующими структурами и классами. Но wcf-proxy-generator (svcutil) удалил некоторые поля (объявленные как только для чтения) и недостаточно умен для псевдонимов (например: public bool Boolean1 { get { return Booleans[0] }} превращен в bool Boolean1 { get; set; }).

Я решил дублировать такие унаследованные классы, чтобы устранить путаницу. Теперь для некоторых из существующих классов существует контрактная версия. & У WCF-сервиса есть дополнительный код, который переводит безопасные по контракту классы в устаревшие версии & наоборот.

Вы бы предложили дублировать все устаревшие классы или это нормально, чтобы преобразование было только для проблемных? Может быть, есть некоторые дополнительные параметры генератора прокси, которые я пропустил.

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

ответ

1

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

Было бы проще изменить ваши устаревшие классы как WCF-friendly, но, как правило, это не вариант. Классы, созданные для преобразования из унаследованного класса в класс, совместимый с WCF, кажутся прекрасными, но, очевидно, не идеальными, поскольку вы вводите другой уровень, чтобы использовать эти классы с WCF.

+0

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