Предоставить стороннему интерфейсу (через WCF) Silverlight - PullRequest
Новая
       2

Предоставить стороннему интерфейсу (через WCF) Silverlight

0 голосов
/ 12 августа 2010

Я много искал, извиняюсь, если пропустил что-то очевидное. И спасибо за чтение нижеследующего текста ниже.

У меня есть стороннее приложение (читай: нет доступа / изменения источника) здесь. Он состоит из сервера (службы Windows) и API, который взаимодействует с сервером через удаленное взаимодействие. По нескольким причинам я хотел бы представить этот API поверх WCF (см. Тему: одна из причин - клиент WCF).

Проблема в том, что API

  1. неизменяемый (следует правилу третьей стороны)
  2. без использования самого WCF (он является сериализуемым / MarshalByRef, где это необходимо для удаленного взаимодействия)
  3. с использованием большого количества интерфейсов и внутренних классов реализации

После 1 я не могу использовать (довольно навязчивые) атрибуты WCF самостоятельно.

После 2 сам API можно использовать «по проводам» (они поддерживают удаленное взаимодействие через TCP и HTTP), но удаленное взаимодействие мне не подходит.

После 3 у меня есть в основном интерфейсы (которые WCF не будет хорошо обрабатывать, не может (де) сериализовать). Классы реализации могут быть отправлены, но я не могу получить к ним доступ.

Общее использование этого API основано на одном интерфейсе (и его элементах / свойствах), поэтому типичное использование похоже на 

var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();

и т. Д.

Что я действительно хотел бы сделать, так это сгенерировать (с минимальными усилиями / кодом, насколько это возможно) прокси (не в обычном смысле WCF), который я предоставляю через WCF и который сериализует эту иерархию, отображая каждый вызов / свойство в клиент к реальной вещи на сервере.

Ближайший, к которому я так далеко, наткнулся на этот проект , но мне интересно, есть ли еще / другие доступные инструменты, которые снимают среднюю или большую часть этой работы с моего плеча.

Если есть какие-либо общие советы, более эффективные подходы, чтобы обернуть что-то существующее и неизменное в WCF, пожалуйста, поделитесь.

Ответы [ 2 ]

0 голосов
/ 14 августа 2010

Ладно, мозги # 1 на моей стороне:

  1. Используйте меню Visual Studio Refactor для «извлечения интерфейса» в «ApiClientEntryPoint».
  2. Создайте новую службу WCF, которая реализует описанный выше интерфейс, и получите VS для генерации заглушек метода.
  3. 'Для PropertyExposingAnInterface.SomeOtherMethodCall' Вам придется сгладить интерфейсы, поскольку отсутствует понятие «вложенной» операции службы.

Единственным другим вариантом будет использование кода T4 gen, что, вероятно, займет больше времени, чем приведенная выше идея.

0 голосов
/ 12 августа 2010

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

Это будет работать в большинстве, но не во всех сценариях. Я не уверен в вашем конкретном сценарии, так что YMMV.

Кстати, вы можете посмотреть на WCF RIA Services, которая хороша для предоставления сервисов Silverlight, где вы можете избежать ручного кодирования сервисного материала. Но опять же, в зависимости от вашего конкретного сценария, это может быть не лучшим вариантом.

Edit:
Теперь ясно, что API слишком велик и / или шаблоны использования клиентов слишком разнообразны, чтобы эффективно использовать фасад. Единственное, что я могу предложить, это посмотреть на использование инструмента генерации кода. Используйте рефлексию (предполагая, что это .NET API?), Чтобы отделить API, а затем кодировать новые сервисы, используя собранную вами информацию. Вы можете взглянуть на шаблоны T4, встроенные в Visual Studio, или на более «надежный» инструмент, такой как CodeSmith. Но я предполагаю, что это был бы болезненный код для написания. Я не знаю об автоматизированном решении для этого.

Хорошо ли задокументирован API? Если да, то есть ли документация в разбираемом формате, таком как XML или хорошо структурированный HTML? В этом случае вы можете кодировать из документации, а не размышлять через код. Это может быть быстрее в зависимости от подробностей.

...