Архитектура приложения с использованием WCF и System.AddIn - PullRequest
1 голос
/ 04 апреля 2009

Немного предыстории - мы разрабатываем приложение, которое использует архитектуру клиент / сервер, состоящее из:

  • Сервер, который загружает серверные модули, потенциально разработанные другими командами.
  • Клиент, который загружает соответствующие клиентские модули (также потенциально разработанные другими группами; каждый клиентский модуль соответствует серверному модулю).
  • Клиентская сторона связывается с серверной стороной для общей координации, а также для конкретных задач модуля. (На данный момент, я думаю, это означает, что клиент общается с сервером, клиентские модули общаются с серверными модулями.)
  • Средой является .NET 3.5, а на стороне клиента - WPF.

Сценарий развертывания предоставляет возможность обновлять сервер, любой серверный модуль, клиент и любой клиентский модуль независимо. Тем не менее, требуется возможность «работать» с использованием несовпадающих версий. Поэтому я обеспокоен проблемами с версиями.

Пока я думаю:

  • Служба Windows для сервера.
  • Использование System.AddIn для сервера для загрузки и взаимодействия с серверными модулями даст нам наибольшую гибкость в плане совместимости версий между серверным и серверным модулями.
  • Сервер и каждый серверный модуль предоставляют услуги WCF для связи на стороне клиента; связь между сервером и модулем сервера или между двумя модулями сервера использует контракты AddIn. (Одним из преимуществ этого является то, что модуль может предоставлять другой интерфейс внутри сервера и за его пределами.)
  • Аналогично, клиент использует System.AddIn для поиска, загрузки и связи с клиентскими модулями.
  • Связь клиента с клиентскими модулями осуществляется через интерфейс AddIn; связь от клиента и от клиентских модулей на стороне сервера осуществляется через WCF.
  • Для максимальной устойчивости каждый модуль будет работать в отдельном домене приложений.
  • В целом, система предъявляет скромные требования к производительности, поэтому не следует ожидать, что упорядочение и пересечение границ процесса будут представлять проблему с точки зрения производительности. (Требования к производительности в основном суммируются: не мешайте другим частям системы, не описанным здесь.)

Мои вопросы связаны с идеей использования двух разных моделей взаимодействия и управления версиями, что станет дополнительным бременем для наших разработчиков. System.AddIn кажется довольно мощным, но также немного громоздким. (Я также не уверен в приверженности Microsoft к этому в будущем.) С другой стороны, я не в восторге от возможностей управления версиями в WCF. У меня есть ощущение, что можно было бы реализовать систему представления / адаптера / контракта System.AddIn в WCF, но, будучи довольно новым для обеих технологий, я бы не знал, с чего начать.

Итак ... Я на правильном пути? Я делаю это трудным путем? Есть ли ошибки, о которых мне нужно знать на этом пути?

Спасибо.

1 Ответ

0 голосов
/ 04 апреля 2009

Это звучит слишком сложно. Рассмотрим архитектуру, в которой каждый добавленный модуль включает в себя как код на стороне клиента (если хотите, используйте System.AddIn), так и модуль на стороне сервера - это новый файл service.svc. Клиент будет знать URL-адрес соответствующей службы.

В качестве альтернативы вы должны обратиться к Microsoft Extensibility Framework (MEF) для функции надстройки. Это то, что они начнут использовать для расширяемости Visual Studio в следующем выпуске.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...