Un conteneur IoC remplace-t-il l'utilisation des usines

Question

Je commence tout juste à utiliser des conteneurs IoC, alors veuillez m'excuser si cette question est stupide.

J'ai le code suivant dans une application

internal static class StaticDataHandlerFactory
    {
        public static IStaticDataHandler CreateHandler(StaticDataUpdate staticDataUpdate)
        {
            if (staticDataUpdate.Item is StaticDataUpdateOffice)
            {
                return new OfficeUpdateHandler();
            }

            if (staticDataUpdate.Item is StaticDataUpdateEmployee)
            {
                return new EmployeeUpdateHandler();   
            }

            if (staticDataUpdate.Item == null)
            {
                throw new NotImplementedException(
                    string.Format("No static data provided"));
            }
            else
            {
                throw new NotImplementedException(
                    string.Format("Unimplemented static data type of {0}", staticDataUpdate.Item.GetType().FullName));
            }
        }
    }

Il s’agit essentiellement d’une fabrique simple qui renvoie la stratégie appropriée pour gérer les données d’entrée.

Un conteneur IoC me permettrait-il d'éliminer un code de ce type? Cela me permettrait-il de choisir dynamiquement une implémentation concrète à charger en fonction du type d'un paramètre d'entrée?

Ou suis-je hors de propos ici?

Answer 1

En fait, bien qu'il soit possible de remplacer une partie du code par une inversion du système de contrôle, ce n'est pas évident pour moi, c'est une bonne idée. L'injection de dépendance tend à être préférable pour la configuration des systèmes, pas pour la création dynamique d'objets. En d'autres termes, le conteneur lui-même est une énorme variable globale et, en tant que telle, devrait apparaître dans une grande partie de votre code.

De plus, le code semble violer le Loi de Demeter . Il semble que le paramètre soit de type "StaticDataUpdateItem". plutôt que "StaticDataUpdate". Cela dit, il existe un argument assez puissant pour réécrire ce code en tant qu’appel de méthode sur StaticDataUpdateItem.

J’ai beaucoup utilisé IoC, mais la création d’objets dynamiques est encore mieux traitée avec un modèle de fabrique abstraite. En bref, si vous n’aimez pas l’idée d’ajouter une méthode à l’élément lui-même pour générer le descripteur, il est probablement préférable de laisser le code tel quel.

Answer 2

Vous n'êtes pas loin du tout; Si je comprends bien, vous êtes assez proche.

La manière la plus courante de structurer ce genre de chose est de transformer votre classe Factory en votre conteneur IoC, simplement en permettant à UpdateHandler qui est renvoyé d'être spécifié à l'aide de Dependency Injection. Ainsi, au lieu d'avoir dans votre code la logique qui spécifie que StaticDataUpdateOffice signifie de renvoyer OfficeUpdateHandler, vous pouvez transformer votre code en indiquant simplement que StaticDataUpdateOffice renvoie tout ce qu'une variable (récemment spécifiée) m_officeUpdateHandler contient; tant que votre Framework s'assure que vous définissez la valeur de m_officeUpdateHandler avant d'appeler votre fabrique, vous pouvez continuer. Et vous pouvez modifier la valeur de m_officeUpdateHandler en tout ce que vous voulez au moment de l'exécution, à mesure que vos besoins évoluent.

Cette injection de dépendance vous permet de contrôler le processus d'inversion de contrôle. vous pouvez avoir une fabrique simple qui renvoie vos gestionnaires, et vous pouvez résumer la logique qui contrôle le gestionnaire renvoyé à un emplacement différent, le cas échéant.

Remarque: mon expérience avec ce genre de choses est plutôt fortement motivée par mon expérience (très positive) avec Spring, ce qui peut donc influencer mon interprétation de votre question (et de la réponse).

Answer 3

La réponse courte est oui, cela le permet. Cette article de blog s'affiche. un moyen astucieux de choisir la mise en œuvre au moment de l'exécution à l'aide de Windsor. L’auteur, Ayende, élabore ici et ici .

Je n'ai pas encore essayé, mais je m'attends à bientôt.

Answer 4

Je suis d’accord avec les autres réponses ici, à savoir que oui, vous pouvez le faire de cette façon. Mais pourquoi ne pas utiliser un générique?

public static IStaticDataHandler CreateHandler<T>( params object[] args )
{...

où les arguments peuvent être passés en tant qu'arguments ctor (à, par exemple, Activator).

Answer 5

Je n'ai encore lu aucun mot qui ait beaucoup de sens.

IoC est plus pour la configuration?

La création d'objet dynamique, c'est mieux quoi? Génériques? Tout ceci est hors sujet.

1) IoC n’est qu’un gain de temps appréciable par rapport à la mise en œuvre de l’Évangile «Composition sur spécialisation / héritage».

Donc, la règle n ° 1 pour utiliser un IoC est que vous devriez être vraiment fatigué de devoir traiter avec de longs constructeurs qui suivent la clause 'bind to contract not implementation'.

En d'autres termes, il s'agit du modèle stratey comme alternative au modèle pour les mêmes raisons (encapsulation ...) ... MAIS il est plus difficile de créer tous les types d'interface / abstraits supplémentaires et c'est plus travaillez pour le faire CHAQUE FOIS avec tous les IServiceProvicerThis et IResolverThat ... Si vous n'êtes pas fatigué d'avoir à remplir péniblement des contrats de code tels que:

IInterestingService intéressant = ... vous obtenez cependant une instance ..

ajouter environ trois autres lignes comme celle-ci ..

puis

Service IAmazementService = nouvel AmazementService (intéressant, deuxième stratégie, troisième, etc.)

Ça vieillit. Donc, IoC n'est jamais une question, car quiconque assez intelligent pour coder en utilisant une conception solide en saura davantage. Ceux qui demandent ont toutes les mauvaises réponses.

Donc si vraiment vous rencontrez ce qui précède, alors absolument. Les conteneurs IoC sont sur le point d'accomplir le plus de travail «créatif» possible en leur laissant la possibilité de s'en occuper. Et l'abstrait de création le plus courant par rapport au nouveau explicite est M. Factory.

Damon