Problème de mise en œuvre du modèle Interceptor

Question

Je tente de développer un framework Interceptor (en C#) où je peux simplement implémenter certaines interfaces, et en utilisant une initialisation statique, enregistrer tous mes intercepteurs avec un Dispatcher commun pour être invoqué à un plus tard. Le problème réside dans le fait que mes implémentations Interceptor ne sont jamais réellement référencées par mon application, donc les constructeurs statiques ne sont jamais appelés, et par conséquent, les Interceptor ne sont jamais enregistrés.

Si possible, je voudrais garder toutes les références à mes bibliothèques Interceptor hors de mon application, car c'est ma façon d'imposer (espérons-le) le couplage lâche entre différents modules.

Espérons que cela a du sens. Faites-moi savoir s'il y a quelque chose que je peux clarifier ...

Est-ce que quelqu'un a des idées, ou peut-être une meilleure façon de mettre en œuvre mon modèle Interceptor?

Mise à jour: Je suis tombé sur Spring.NET. J'en ai déjà entendu parler, mais je n'y ai jamais vraiment réfléchi. On dirait qu'il a beaucoup de fonctionnalités qui seraient très utiles pour ce que j'essaie de faire. Est-ce que quelqu'un a une expérience avec Spring.NET?

TIA,
Jeremy

Answer 1

Je recommande vivement regardant certains de l'aspect existant cadre de programmation orientée (AOP) pour .NET car ils vont probablement accomplir ce que vous essayez d'atteindre dans une plus généralisée et maintenable mode. La plupart d'entre eux sont open source, donc quand ils ne répondent pas à vos besoins, vous pouvez étendre et contribuer au (x) projet (s).

Plus de détails: http://www.sharpcrafters.com/aop.net

Answer 2

Spring.Net, cadre fédérateur et StructureMap sont probablement votre meilleur pari. Ce que j'ai fait dans le passé est MVC utilisé et a créé une usine de contrôleur personnalisé pour générer mes contrôleurs. Cependant, l'utilisation de l'injection de dépendances est devenue difficile avec des frameworks comme NinJect en raison de l'absence de configuration XML (Ninject utilise une API fluide). La raison pour laquelle c'est difficile est que vous n'êtes pas sûr à l'exécution de quels modules vous aurez besoin de l'injection de dépendance. Les trois conteneurs IOC ont avant tout une forme de configuration XML qui peut être modifiée en dehors de votre compilation et donc rendre votre application plus modulaire, donc il n'y aurait pas (espérons-le) besoin d'initialisation statique. Le plus important étant que vous n'avez pas à vous soucier autant de la sécurité des threads.