Расширяемая структура / шаблон / передовой опыт для веб-сервисов?

Question

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

Проблема заключается в том, что различным клиентам требуются разные функции / алгоритмы, и я не знаю, как обеспечить расширяемостьна стороне сервера.Для клиентской части (Silverlight) я могу использовать MEF / Prism, но я не уверен, что будет хорошим подходом для решения этой проблемы на сервере.

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

Есть ли:

a) рамки / библиотеки

b) шаблоны

c) хорошие практики

, которые бы мне помоглимодулировать приложение и сделать выбор требуемых модулей и их развертывание относительно простым?

Answer 1

Мне кажется, что требуется инверсия зависимостей: изолировать логические части системы (алгоритмы и т. Д.) Путем определения интерфейсов, а затем использовать инфраструктуру DI / IoC для загрузки требуемой реализации во время выполнения (или при запуске приложения и т. Д.).

Я не использовал Ninject , но многим это нравится, так что вы можете попробовать это; есть также Spring.Net .

Хорошие практики:

• Убедитесь, что у вас есть четкая и точная регистрация, чтобы вы знали, что и когда используется.
• Подумайте, хотите ли вы, чтобы реализация «по умолчанию» загружалась в случае сбоя желаемой реализации, или же вы намеренно хотите потерпеть неудачу, чтобы неправильные данные не были возвращены по ошибке (например, при использовании другого алгоритма).
• Я обнаружил, что использование атрибутов для украшения инъекционных модулей действительно полезно (особенно в веб-системе, к которой у вас нет непосредственного доступа), одна из причин этого заключается в том, что вы можете создавать страницы или элементы управления, которые перечисляют все известные / доступные реализации во время выполнения.

Вы также можете использовать атрибутивный подход для создания пользовательского интерфейса, который позволяет пользователям выбирать, какой из них они хотят; Я использую его для созданного мной фреймворка с открытым исходным кодом: http://www.morphological.geek.nz/Morphfolia/Capabilities/AttributeDriven.aspx