CIO à la compilation

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

De nombreux conteneurs IOC sont lents à démarrer, car une grande partie de la logique de résolution se produit ici
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é
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
source

Réponses:

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
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

"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

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
source