Передача плохо структурированной информации в метод WCF. Лучшая практика - PullRequest
0 голосов
/ 27 июля 2010

У меня есть устаревший класс Reporting Engine, который отвечает за 50+ отчетов одним методом CreateReport(Guid reportId, ReportParams params);

Для отчетов требуется 12+ различных типов параметров (Guid, int, bool, перечисления) и их комбинация. Например:

  • Отчет № 1: параметры не требуются
  • Отчет № 2: 2 логических значения (флажки устанавливаются пользователем)
  • Отчет № 3: Guid (personId) и целое число (год, с которого начинается)
  • Отчет № 4: Guid (personId) и PersonType (перечисление)

ReportParams - это класс с более чем 12 свойствами и массивами, которые заполняются перед вызовом метода. Но большинство из них не используются за звонок. Класс Report Engine проверяет, заполнены ли соответствующие свойства, и использует доступ к информации строгого типа.

Все было хорошо, пока я не решил сделать механизм отчетов WCF дружественным. Каждый раз, когда я добавляю новый тип параметра, мне приходится перестраивать сервер, обновлять прокси-сервер (что приводит к переустановке клиентов) и следить за тем, чтобы структура ReportParam правильно конвертировалась между версией WCF-совместимой и версией Reporting Engine.

Интересно, как минимизировать все эти преобразования, проверки, переустановки клиентов и т. Д. Может быть я реорганизую ReportParam в XML-документ? Это сделает прокси стабильным, ReportParams wcf дружественным, но мне придется реорганизовать доступ к информации строгого типа в классе механизма отчетов.

Что вы предложите?

Ответы [ 2 ]

1 голос
/ 27 июля 2010

Контролируете ли вы оба конца связи WCF ??

В этом случае:

  • поместите ваш контракт на обслуживание (интерфейс) и контракты данных в сборку библиотеки классов
  • поделитесь этой сборкой между сервером и клиентом
  • на клиенте, используйте ChannelFactory<T> и factory.CreateChannel(), чтобы вручную создать канал связи

В этой настройке вы выполняетеизмените контракт данных один раз, перестройте свой сервис и клиента, и все готово.Нет грязных "Справочник по сервису обновления" и т. Д.

0 голосов
/ 27 июля 2010

Я не совсем ясно по вашей проблеме, но позвольте мне не останавливаться на этом в моем ненасытном поиске представителя.

Во-первых, я бы определенно предложил разместить «межсетевой экран» между кодом отчетности и кодом WCF. Вы должны рассматривать ваш код WCF как фасад , максимально изолируя его от изменений в ваших отчетах. Если ваш механизм отчетов требует изменений, вы можете переписать код сервера, не связываясь с кодом клиента.

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

Но вы спрашиваете, что произойдет, когда отчет изменится, или новый отчет должен быть добавлен? Вы не можете (т.е. не должны ни при каких обстоятельствах) создавать версии интерфейсов, и ваш контракт на обслуживание является интерфейсом. Следовательно, при изменении отчетов необходимо пометить метод отчета OLD как устаревший. Добавьте обновленный метод (а также методы для новых отчетов) в НОВЫЙ контракт на обслуживание, который будет обслуживаться рядом со старым. Если люди пытаются использовать старый метод отчета, либо попытайтесь сделать должное (примените разумные значения по умолчанию к тем аргументам, которые не предоставлены), либо сгенерируйте исключение. Если отчет резко изменяется до точки, в которой требуется переустановка клиента, рассмотрите возможность добавления обновленного отчета в качестве нового.

Добавление обновленных отчетов и / или новых отчетов становится простым делом удаления нового двоичного файла на сервере и изменения файла .config.

...