Проблема реализации шаблона перехватчика

Question

Я пытаюсь разработать инфраструктуру Interceptor (в C #), где я могу просто реализовать некоторые интерфейсы и, используя некоторую статическую инициализацию, зарегистрировать все мои Interceptor с помощью общего Dispatcher, который будет вызван позднее.

Проблема заключается в том факте, что мое приложение никогда не ссылается на мои реализации перехватчика, поэтому статические конструкторы никогда не вызываются, и в результате перехватчики никогда не регистрируются.

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

Надеюсь, в этом есть какой-то смысл. Дайте мне знать, если я смогу уточнить ...

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

Обновление: Я сталкивался с Spring.NET. Я слышал об этом раньше, но никогда не задумывался об этом. Похоже, у него есть много замечательных функций, которые были бы очень полезны для того, что я пытаюсь сделать. У кого-нибудь есть опыт работы с Spring.NET?

ТИА
Джереми

Answer 1

Spring.NET, Unity Framework и StructureMap - это, вероятно, ваш лучший выбор. В прошлом я использовал MVC и создал собственную фабрику контроллеров для генерации моих контроллеров. Однако использование внедрения зависимостей стало затруднительным для таких сред, как NinJect, из-за отсутствия конфигурации XML (Ninject использует свободный API). Причина, по которой это трудно сделать, заключается в том, что вы не уверены во время выполнения, для каких модулей вам понадобится внедрение зависимостей.

Три контейнера IOC, прежде всего, имеют некоторую форму конфигурации XML, которая может быть изменена вне вашей компиляции и, следовательно, помогает сделать ваше приложение более модульным, поэтому не будет (надеюсь) необходимости в статической инициализации. Главный плюс в том, что вам не нужно беспокоиться о безопасности потоков.

Answer 2

Я настоятельно рекомендую взглянуть на некоторые из существующих платформ AOP-ориентированного программирования (AOP) для .NET, поскольку они, скорее всего, достигнут того, чего вы пытаетесь достичь, более обобщенным и понятным способом. Большинство из них с открытым исходным кодом, поэтому, если они не соответствуют вашим потребностям, вы можете расширить и внести свой вклад в проект (ы).

Подробнее: http://www.sharpcrafters.com/aop.net