Структура для загрузки различных веб-ссылок в качестве плагина

Мы разработали приложение на C# .NET, которое синхронизирует данные (клиенты, заказы) с приложением электронной коммерции PHP с использованием SOAP.

WSDL приложения PHP добавляется в качестве веб-ссылки.NET 2.0 к нашему приложению, поэтому.NET Framework генерирует классы и функции для взаимодействия с веб-службой SOAP. Например, мы можем отправить информацию об акциях следующим образом:

catalogInventoryStockItemUpdateEntity stock = new catalogInventoryStockItemUpdateEntity();
stock.is_in_stock = 1;
stock.is_in_stockSpecified = true;
stock.qty = "10";
webserv.catalogInventoryStockItemUpdate(sessionid, itemcode, stock);

Это прекрасно работает, однако мы часто работаем в ситуациях, когда один из наших клиентов имеет дополнительные (нестандартные) поля, определенные в WSDL, и хочет, чтобы эти поля использовались при синхронизации. Наша текущая практика состоит в том, чтобы создать новую ветвь нашего кода для этого клиента и обновить веб-ссылку для использования конкретного WSDL нашего клиента.

Чтобы мы не могли получить длинный неосуществимый список ветвей нашего программного обеспечения, я планирую полностью пересмотреть структуру нашего приложения. Теперь мне интересно, что будет лучшей структурой, чтобы справиться с этим. Я думал поместить веб-ссылку в свой собственный класс и динамически загружать эту DLL, поэтому, если у клиента есть нестандартный WSDL, мы можем создать его собственный класс и загрузить его как "плагин" в наше программное обеспечение. Но дополнительные поля в (например) catalogInventoryStockItemUpdate будут по-прежнему недоступны в основной части нашего приложения.

Есть ли инструменты, которые могут помочь в достижении этого? Я хотел бы иметь одно основное приложение для синхронизации и поместить все специфичные для клиента отображения и ссылки на WSDL в отдельный класс / проект.

Источник

1 ответ

Решение

Прежде всего, для добавления поддержки плагинов в ваше приложение вы можете использовать Microsoft Extensibility Framework (MEF). Если вы ограничены использованием.NET 2.0, то есть другие собственные способы обнаружения и загрузки плагинов (через отдельные домены приложений или путем загрузки их прямо в основной домен приложения).

Что касается дизайна, я бы сделал каждый плагин:

  1. Удерживайте ссылку службы на ее конкретный экземпляр веб-службы.
  2. Сделайте какие-либо конкретные назначения или логику для этой службы. Например назначить 10 в stock.qty,
  3. Предоставьте обратные вызовы / события, которые приложение может использовать для вмешательства в логику, реализованную в плагине. Например, вы могли бы, чтобы плагины выставляли событие под названием BeforeStockSubmitted и вы могли бы сделать некоторые проверки или проверки в приложении данных, передаваемых в службу.

Ваш хост плагина (приложение или его модуль) должен:

  1. Предоставьте согласованную объектную модель для всех плагинов. Вы должны предложить определенную степень абстракции для всех сущностей, с которыми будут работать плагины (например, sessionId, stock, так далее).
  2. Данные, поступающие в плагины, также должны быть абстрагированы. Таким образом, вы можете иметь IStockInfo интерфейс в хосте, и каждый плагин должен быть ограничен, чтобы обеспечить свою собственную реализацию. Хост может заполнять общие свойства этих объектов, в то время как плагин заботится о конкретной части.
Источник
Другие вопросы по тегам