CIO à la compilation

11

Quelqu'un a-t-il démarré un projet pour faire IOC au moment de la compilation (éventuellement en utilisant Roslyn ou Linq MethodInfo emit)?

Jusqu'à présent, mon expérience avec les conteneurs IOC a été formidable, mis à part quelques petits problèmes

  1. De nombreux conteneurs IOC sont lents à démarrer, car une grande partie de la logique de résolution se produit ici
  2. Il est souvent difficile de s'assurer que la résolution est possible, car la compilation ne garantit plus que le constructeur peut être appelé
  3. Souvent, les conteneurs IOC ajoutent une petite surcharge à l'exécution (certains ne sont même pas petits, souvent ceux qui démarrent rapidement s'exécutent lentement)

Il me semble que la solution idéale serait d'ajouter une étape de compilation à la chaîne de construction qui ajoute une classe Factory au lieu d'IOC.

Quelqu'un a-t-il déjà fait cela? Sinon, pourquoi pas?

c# meta-programming inversion-of-control ArTs
la source

Réponses:

4

Faire cela ne devrait pas être un tel problème. Exécutez simplement la même logique IoC et au lieu d'instancier les classes, vous émettez du code qui effectue l'instanciation.

Mais en faisant cela, vous supprimez un énorme avantage de l'IoC: la possibilité de modifier la composition des coponents sans avoir à recompiler l'application entière. En remplaçant simplement la configuration, vous pouvez faire en sorte que l'application utilise différents services ou sources de données. Et bien que je n'aie pas encore vu d'application qui exploiterait pleinement cette capacité, c'est toujours une partie importante du succès d'IoC.

Euphorique
la source
Oui je sais que c'est possible. Mais je dois encore voir un conteneur IoC qui le fait. J'ai également noté que la tendance actuelle semble être vers l'enregistrement en code (API fluentes). Compte tenu de cela, j'envisage d'écrire ledit conteneur IoC.
ArTs
Il me semble que Hiro ( github.com/philiplaureano/Hiro ) pourrait faire son travail au moment de la compilation.
lzcd
2
"Mais en faisant cela, vous supprimez un énorme avantage de l'IoC: la possibilité de changer la composition des coponents sans avoir à recompiler toute l'application." Il me semble que l'appliquer à l'ensemble de l'application est exagéré; vous transformez chaque partie de l'application en plug-in. De plus, les deux techniques devraient pouvoir coexister - il n'y a aucune raison pour que vous ne puissiez pas câbler certains composants au moment de la compilation et d'autres au moment de l'exécution.
Doval
Je ne vois pas en quoi c'est un énorme avantage. Dans quel contexte remplacez-vous complètement les composants lors de l'exécution? Quelques cas d'utilisation de configuration peut-être?
andyczerwonka
4

Dagger pour Java / Android fait cela. Il sacrifie un peu de magie d'exécution (comme celle de Guice) pour offrir une expérience de codegen presque complètement à la compilation, y compris la conversion de la plupart des erreurs d'exécution en erreurs de compilation.

Ce serait cool aussi en .NET.

orip
la source