Bibliothèques d'injection de dépendance Ruby

Question

J'ai examiné certaines bibliothèques d'injection de dépendance Ruby. En particulier, j'ai vérifié Needle et Copland. Ils ont été autour pendant un certain temps, mais pas beaucoup d'usages.

Quels sont les avantages et les inconvénients de l'utilisation de ces deux bibliothèques? Il semble bien que beaucoup de bibliothèques/frameworks pourraient faire bon usage de ces deux bibliothèques, par ex. Merb/Datamapper's Hook.

Answer 1

Jamis Buck, qui a écrit Copland and Needle, posted here sur Aiguille, l'injection de dépendance et leur utilité dans un monde Ruby.

Il est long mais mérite d'être lu, mais si vous voulez que le paragraphe le plus pertinent à votre question, je vous suggère de celui-ci, à partir juste avant la fin:

cadres de DI ne sont pas nécessaires. En plus les environnements rigides, ils ont de la valeur. Dans les environnements agiles comme Ruby, pas autant que ce soit en . Les modèles eux-mêmes peuvent encore être applicables, mais méfiez-vous de tomber dans le piège de penser que vous avez besoin d'un outil spécial pour tout. Ruby est Play-Doh, rappelez-vous! Gardons comme ça.

HTH

Answer 2

est ici un plus IoC http://alexeypetrushin.github.com/micon

Je l'ai utilisé en tant que composante essentielle de mon framework web (non Rails), vous pouvez le voir travailler ici - http://ruby-lang.info (ce site alimenté avec elle). Et cela m'a sauvé beaucoup de temps et de code, donc je trouve personnellement IoC très utile (dans certaines situations).

Les structures DI ne sont pas nécessaires. Dans des environnements plus rigides, ils ont de la valeur. Dans des environnements agiles comme Ruby, pas tellement. Les modèles eux-mêmes peuvent encore être applicables, mais prenez garde de tomber dans le piège de penser que vous avez besoin d'un outil spécial pour tout. Ruby est Play-Doh, rappelez-vous! Gardons ça comme ça.

que je regardais parler de Jamis Buck, et je suis d'accord et en désaccord l'esprit, voici pourquoi http://ruby-lang.info/blog/you-underestimate-the-power-of-ioc-3fh

Answer 3

http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/: ceci est un autre article beaucoup moins que l'article opiniâtres James Buck. En résumé, vous n'avez pas besoin d'injection de dépendance car ruby ​​offre de nombreuses bonnes alternatives qui fonctionnent aussi bien et qui n'existent pas vraiment dans le monde Java. L'une de ces alternatives est mixins, ce que Java n'a pas et l'autre est la possibilité de redéfinir/redéfinir à peu près n'importe quoi dans la langue. Les autres fonctionnalités comprennent la frappe dynamique où vous pouvez envoyer n'importe quel message à n'importe quel objet et s'il arrive à fournir une implémentation pour ce message, les choses fonctionnent. Toutes ces choses travaillent ensemble pour éliminer une grande partie du besoin d'un cadre de DI. Le motif de design en tant que tel est toujours valable dans Ruby et parfois il est logique de l'utiliser. Un autre point à propos de DI que fait aussi Alexey Petrushin est que l'injection de dépendance est avant tout un modèle de conception et que l'outillage est secondaire et surtout pour se débarrasser de l'ennui de certaines choses en Java. Dans ruby, vous pouvez émuler de manière triviale la plupart de ce que le printemps ou le guice font pour vous en Java.Donc, un framework d'injection de dépendances complet est essentiellement redondant dans Ruby. Cela étant dit, avoir parfois un cadre DI est un peu sympa car finalement, il peut enlever une partie de l'ennui des choses de câblage. Je ne peux pas me porter garant pour des frameworks DI spécifiques à Ruby mais je connais beaucoup de projets Ruby qui ont été réécrits dans une autre langue (Java même) parce que la nature playdoh rend les choses difficiles à maintenir/étendre. Je soupçonne que cela a beaucoup à voir avec les développeurs se tirant dans le pied avec les différentes fonctionnalités linguistiques puissantes. Avoir un cadre DI impose un peu de structure et d'idiomes qui peuvent aider à prévenir cela.