Question sur DI et comment résoudre certains problèmes

Question

Je suis un débutant à l'injection de dépendance. Je n'ai jamais utilisé et je n'ai même jamais méconnu ce dont il s'agit, mais après ma dernière attaque sur ce sujet, j'ai découvert que c'est un moyen de découpler un objet et ses dépendances, une fois qu'ils ne sont pas responsables d'instancier les versions concrètes de dépendances plus, comme maintenant le conteneur le fera pour nous et livrera l'objet prêt dans nos mains.

Maintenant, le point est; "Quand devrais-je l'utiliser?", TOUJOURS ??? En fait, comme je suis un novice et que je n'ai jamais vu un projet utilisant ce modèle, je ne peux pas imaginer comment je devrais l'appliquer à mes objets de domaine !!! Il me semble que je n'instancierai jamais plus mes objets et le conteneur le fera toujours pour moi, mais alors quelques doutes ...

1) Qu'en est-il des oobjects qu'une partie de ses dépendances provient de l'interface utilisateur, par exemple ;

public class User(String name, IValidator validator) 

dire que je reçois le nom d'utilisateur de l'interface utilisateur, alors comment va le savoir conatiner et encore delliver cet objet pour moi?

2) Il y a d'autres situations auxquelles je suis confronté; si une dépendance est maintenant un objet qui est déjà instancié, disons ... un objet SINGLETON, par exemple. J'ai vu theres paramètres concernant la durée de vie de la dépendance beign injecté (im parler de Spring.NET, par exemple, http demande portée) ... MAIS, demande et d'autres choses liées au Web sont sur ma couche de présentation, alors comment est-ce que je pourrais lier ma couche de présentation et ma couche de domaine sans casser aucune règle de conception (comme mon domaine devrait être totalement ignorant où il est consommé, ne pas avoir de dépendance de couche, etc)

Je serai ravi d'avoir de vos nouvelles . Merci beaucoup.

Answer 1

En général, une fois que vous allez IoC, vous avez tendance à vouloir enregistrer TOUT avec IoC et que le conteneur crache des objets complètement hydratés. Cependant, vous évoquez des points valables. Peut-être une définition de «dépendance» est dans l'ordre; dans son sens le plus large, une dépendance est simplement un ensemble de fonctionnalités (interface) qu'une classe donnée nécessite une implémentation concrète pour que la classe fonctionne correctement. Ainsi, la plupart des programmes non triviaux sont remplis de dépendances. Pour faciliter la maintenance, un couplage lâche de toutes les dépendances est généralement préféré. Cependant, même en cas de couplage lâche, vous n'avez pas besoin d'automatiser l'instanciation des dépendances si ces objets nécessitent des informations spécialisées que vous ne voulez pas polluer votre registre IoC. Le but est de coupler librement l'utilisation, pas nécessairement la création. En ce qui concerne le point 1, certains frameworks IoC ne se comportent pas bien avec des paramètres externes donnés. Toutefois, vous pouvez généralement enregistrer un délégué en tant que méthode d'usine. Ce délégué peut appartenir à un objet comme un contrôleur auquel l'interface utilisateur a donné des informations externes. Les connexions sont un exemple parfait: Créez un objet, dites un LoginController, et enregistrez-le avec IoC comme ILoginController. Vous référencerez ce contrôleur sur votre page de connexion, il sera injecté lorsque la page de connexion est instanciée et la page de connexion lui transmettra les informations d'identification saisies. Le contrôleur effectuera alors l'authentification et aura une méthode GetAuthenticatedUser() qui produit un objet User. Vous pouvez enregistrer cette méthode avec IoC en tant qu'usine pour les utilisateurs, et chaque fois qu'un utilisateur est nécessaire, le délégué d'usine sera évalué ou transmis en gros à la méthode dépendante qui l'appellera quand il aura vraiment besoin de l'utilisateur.

Sur le point 2, la configuration d'une instance unique d'un objet est une force du modèle IoC. Au lieu de créer un vrai singleton, avec un constructeur d'instance privée, une instance statique et un constructeur statique pour produire une instance, vous inscrivez simplement la classe avec IoC et lui dites de ne l'instancier qu'une seule fois et d'utiliser cette instance pour toutes les requêtes. La force est la flexibilité; si vous voulez plus tard qu'il y ait plus d'une instance, il vous suffit de changer l'enregistrement. Vous ne cassez aucune règle de modèle de conception de toute façon; la vue aura toujours un contrôleur injecté, que ce contrôleur soit le même pour toutes les pages ou une nouvelle instance par requête.

Answer 2

1) ce constructeur n'est probablement pas le bon à utiliser, peut-être injectez-vous le validateur au mauvais endroit.

2) Neighter Voir ni modèle et ni contrôleur doit être au courant il y a une IoC, il devrait se situer dans l'architecture d'arrière-plan (où les composants MVC sont en fait instanciées)

Vous devez utiliser IoC quand vous vous sentez l'architecture peut devenir complexe et doit être entretenu par beaucoup de gens. Si vous écrivez une application d'entreprise, ou une interface utilisateur que vous pensez étendre avec des plugins, vous en avez probablement besoin, si vous écrivez un utilitaire de ligne de commande, probablement pas.

Answer 3

Vous devez utiliser l'injection de dépendance quand vous voulez l'un des avantages suivants:

• La possibilité de remplacer les modules facilement
• La possibilité de réutiliser des modules entre les parties de l'application ou des applications différentes
• lorsque vous voulez faire du développement parallèle, de sorte que les composants d'un système peuvent être développées de manière isolée et en parallèle, car ils dépendent des abstractions
• lorsque vous souhaitez faciliter la maintenance d'un système à cause de couplage lâche
• Lorsque vous voulez testabilité (une spécialisation de modules de remplacement).C'est l'une des principales raisons pour l'utilisation de DI

Pour répondre à vos questions:

1) Vous pouvez configurer de nombreux conteneurs IoC de sorte que certains paramètres du constructeur peuvent être spécifiés, tandis que d'autres sont résolus par le conteneur . Cependant, vous devrez peut-être réfléchir à la refactorisation de ce morceau de code, car un UserFactory peut être plus approprié, ce qui prend la dépendance du validateur, et a une méthode NewUser qui prend un nom d'utilisateur et retourne un nouvel utilisateur (instanciation directe ou résolution de le conteneur).

2) Chaque application que vous construisez aura une racine de composition, où votre conteneur est configuré, et l'objet racine est résolu. Chaque application aura donc sa propre configuration de l'IoC, de sorte qu'il existe un lien attendu entre le type d'application et les paramètres de configuration. Tous les enregistrements d'abstraction courants peuvent être placés dans un code de configuration qui peut être partagé entre toutes les applications.