Factory vs PicoContainer - Avantages des conteneurs IoC

Question

J'essaie d'ouvrir mon esprit à la fantaisie. IoC principe, et je suis tombé sur l'article : Martin fowler sur IoC

Il donne quelques exemples d'utilisation PicoContainer :

private MutablePicoContainer configureContainer() {
        MutablePicoContainer pico = new DefaultPicoContainer();
        Parameter[] finderParams =  {new ConstantParameter("movies1.txt")};
        pico.registerComponentImplementation(MovieFinder.class, ColonMovieFinder.class, finderParams);
        pico.registerComponentImplementation(MovieLister.class);
        return pico;
    }

et ensuite l'utilisation de l'échantillon :

public void testWithPico() {
        MutablePicoContainer pico = configureContainer();
        MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
        Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
        assertEquals("Once Upon a Time in the West", movies[0].getTitle());
    }

La première pensée qui m'est venue à l'esprit est la suivante : pourquoi utiliser quelque chose d'aussi compliqué que PicoContainer pour configurer la création d'un objet - et en fait appliquer l'injection de dépendances - (je suis un développeur .NET, donc dans .NET, il faudrait probablement utiliser Réflexion ce qui prend du temps), alors que nous pouvons réaliser la même encapsulation de la création d'objet dans (par exemple) Usines o Constructeur avec un système rapide nouveau opérateur.

Une autre chose : configureContainer() est toujours compilé, les types exacts sont spécifiés au moment de la compilation. Alors pourquoi ne pas utiliser des fabriques, et décider dans le fichier de configuration quelle fabrique utiliser ?

Comme cette approche est nouvelle pour moi, je suppose qu'il y a quelque chose qui me manque en termes d'avantages des conteneurs IoC.

Answer 1

Je viens de mettre à jour une réponse liée à cette question ici .

En .Net, je consulterais la documentation relative à la fonction Unity Framework (de MSFT). J'étais également réticent à l'idée de coder en dur les enregistrements d'implémentation, mais avec le temps, je m'en suis remis. Principalement parce que vous pouvez effectivement utiliser une configuration basée sur des fichiers, vous pouvez enregistrer plus d'une implémentation (et marquer chacune d'entre elles pour qu'elles puissent être appelées) et généralement vous n'utilisez pas plus d'une implémentation en production de toute façon.

Le plus grand avantage est le câblage automatique - où vos dépendances sont trouvées pour vous. L'autofilage en chaîne d'un ensemble complexe de classes est très intéressant, ne serait-ce que parce que vous pouvez facilement enregistrer une instance Mock de l'une des 10 classes en question sans toucher au code d'implémentation. Cela conduit à une énorme quantité de testabilité au prix de l'amorçage d'un conteneur. Pour moi, ces jours-ci, c'est un enjeu de table, qui ne vaut même pas la peine d'être discuté. Imaginez que Type1 dépende de 2, 3 et 4, 4 dépende de 5 et 6, 6 dépende de 7. Si je veux tester comment le système réagit à une erreur dans 6, comment puis-je le faire ? Tout ce que j'ai à faire est de simuler (en utilisant un cadre cool comme Moq) Type6, d'enregistrer le simulateur, mais d'utiliser des implémentations réelles pour les autres classes.

[Fact]
public void TestType6BlowingUp()
{
  IocContainer container = new IocContainer();
  container.RegisterType(Type1, Type1Impl);
  container.RegisterType(Type2, Type2Impl);
  container.RegisterType(Type3, Type3Impl);
  container.RegisterType(Type4, Type4Impl);
  container.RegisterType(Type5, Type5Impl);
  container.RegisterType(Type6, Type6Mock);
  container.RegisterType(Type7, Type7Impl);

  Type1 type1 = container.Resolve<Type1>();
  Type1Response response = type1.DoSomethingThatCallsType6Downstream();
  //Should get errorcode 500
  Assert.True("Expected ErrorCode 500", response.ErrorCode == 500);
}