8
votes

Injection IOC / Dépendance - Veuillez expliquer le code versus xml

Je comprends fondamentalement comment fonctionnent les cadres d'IOC, mais une chose que je ne reçois pas tout à fait est de savoir comment la configuration basée sur le code est censée fonctionner. Avec XML, je comprends comment vous pouvez ajouter un nouvel assemblage à une application déployée, puis modifiez la configuration dans XML pour l'inclure. Si l'application est déjà déployée (c'est-à-dire compilée sous une forme), comment peut-on effectuer des modifications de code sans recompilation? Ou est-ce ce que les gens font, changent simplement de configuration dans le code et de recompiler?


0 commentaires

4 Réponses :


2
votes

IOC et DEP L'injection peut aider à autoriser des modifications sans recompilation (selon les outils utilisés), mais ne le nécessite pas. Utilisation du code pour configurer concerne la configuration du conteneur, pas sur les modifications post-déploiement. Oui, si vous apportez la modification du code, vous devez normalement recompiler.


0 commentaires

0
votes

Juste parce qu'un conteneur DI utilise le code de configuration ne signifie pas qu'aucune configuration ne peut être modifiée sans recompilation. Il exige que vous réfléchissiez exactement à ce que vous souhaitez être configurable de cette façon et de fournir un moyen de modifier cette configuration (par exemple via un fichier de propriétés).


0 commentaires

14
votes

Les dépendances à échanger à chaud ne sont pas le seul objectif d'utiliser un conteneur di conteneur.

Injection de dépendance (DI) est un principe qui nous aide à développer Code lâche. L'accouplement desserré seulement signifie que nous pouvons varier les consommateurs et les services indépendamment les uns des autres. comment nous atteignons cela n'est pas abordé à ce niveau.

CONTENANTS DI sont des cadres qui aident à utiliser les dépendances du fil. Ce sont des bibliothèques utilitaires plus ou moins seulement qui nous aident à appliquer des modèles di. Encore une fois, comment nous configurons un conteneur est perpendiculaire à la manière dont nous consommons ces dépendances.

configurations XML nous permet de modifier la configuration du conteneur sans recompilation . Code comme configuration pas.

Toutefois, les dépendances d'échange sans recompilation ne sont généralement pertinentes que pour un petit sous-ensemble de tout votre code couplé lâche. Pour le reste, une approche basée sur la convention est beaucoup plus efficace, car elle a tendance à être moins fragile . Voir ici pour plus d'informations.


1 commentaires

Si vous aimez le mot perpendiculaire, vous aimerez probablement aussi le mot orthogonal. J'aime ce mot.



1
votes

Le changement de code sans recompilation n'est pas possible. Changement de configuration stocké dans web.config, sans rechargement du pool d'applications n'est pas possible. Cependant, vous pouvez utiliser le scénario suivant où vous n'avez pas à recompiler le code ni à recycler le pool d'applications.
1. Stockez vos mappages dans un fichier de configuration externe. (XML va bien)
2. Écrivez une fonction qui charge les mappages du fichier externe à votre conteneur.
3. Exposer une fonction qui recharge les mappages.
4. Chaque fois que vous voulez recharger les mappages, appelez simplement le fichier exposé. méthode et vous êtes bon d'aller :)

Vous pouvez également stocker les mappages, dans un serveur SQL ou tout autre endroit. (Les chargez simplement dans le format requis pour le conteneur pour le traiter.)


0 commentaires