IoC, AOP et plus

Question

Qu'est-ce qu'un conteneur IoC?

Qu'est-ce qu'un cadre IoC/DI? Pourquoi avons-nous besoin d'un cadre pour IoC/DI?

Pourquoi avons-nous besoin d'un cadre pour IoC/DI?

Existe-t-il une relation entre IoC/DI et AOP?

Qu'est-ce que Spring.net/ninject en ce qui concerne l'IoC et l'AOP?

Answer 1

JMSA,

James Kovacs a écrit un article fantastique qui couvre beaucoup de vos questions, je recommande la lecture de ce Here

Spring.Net, Ninject, l'unité, le château de Windsor, Autofac sont tous les conteneurs du CIO qui sont configurable de différentes façons, beaucoup d'entre eux prennent également en charge AOP.

Les frameworks pour IOC/DI sont utiles car ils fournissent des mécanismes standards, par exemple si vous embauchez un nouveau développeur c'est beaucoup plus facile à dire, nous utilisons ce framework et nous leur transmettons les liens vers les tutoriels/aide. Dans le même temps, ces cadres sont testés et testés par une grande communauté/entreprises. Faites-moi savoir si l'une de vos questions reste sans réponse après avoir lu l'article et les réponses ci-dessus et je ferai de mon mieux pour fournir une aide supplémentaire.

Answer 2

Martin Fowler a un bon article here sur la signification de l'inversion de contrôle et de l'injection de dépendance.

L'utilisation de Spring.NET AOP est décrite en détail here. Je suis plus familier avec la version basée sur Java de Spring, donc je ne peux pas dire avec certitude que Spring.NET ne supporte actuellement que l'AOP basé sur un proxy. En d'autres termes, une classe à conseiller doit implémenter une interface. Spring crée un proxy dynamique qui implémente cette interface et délègue à l'instance cible d'origine.

Bien qu'il ne l'état:

Dans un futur proche, nous allons mettre en œuvre des procurations en utilisant l'héritage, ce qui vous permettra de classes proxy sans interfaces aussi bien et va supprimer certaines des questions de référence premières restantes qui ne peuvent être résolu en utilisant des proxies basés sur la composition.

Answer 3

D'un point de vue sémantique ...

injection de dépendances elle-même implique une dépendance , à savoir quelque chose qui est nécessaire pour la construction/utilisation ("préoccupations fondamentales" de l'application). Par exemple, une voiture n'est pas une voiture sans moteur.

Les aspects sont décrits comme étant transversaux aux principales préoccupations de l'application. Cela signifie à la fois séparé et non crucial pour les préoccupations principales (vous pourriez les considérer comme des «biens-à-faire»). Puisque l'application peut fonctionner sans aspects, sont-ils vraiment des dépendances? Par exemple, une voiture est toujours une voiture même sans immobilisateur.

(Bien sûr, c'est d'un point de vue théorique.Dans le monde réel, des questions comme la sécurité sont souvent aussi cruciales pour l'existence d'un produit commercialisable que le noyau concerné.)

Donc, en pratique, DI peut être utilisé pour implémenter des aspects, je n'appellerais pas ce processus vrai DI . Cela vient de quelqu'un qui utilise l'injection de constructeurs exclusivement.