Biblioteki iniekcji zależnej od Rubiego

Question

Przeglądałem biblioteki wstrzyknięć zależnych od Rubiego. W szczególności, sprawdziłem Needle i Copland. Są już od jakiegoś czasu, ale niezbyt wiele zastosowań.

Jakie są zalety i wady korzystania z tych dwóch bibliotek? Wygląda na to, że wiele bibliotek/frameworków może dobrze wykorzystać te dwie biblioteki, np. Merb/Datamapper's Hook.

Answer 1

Jamis Buck, który napisał Copland and Needle, posted here o Needle, zastrzyk zależności i ich przydatność w świecie Ruby.

Jest długi, ale warto przeczytać, ale w przypadku, gdy chcesz pojedynczy paragraf najbardziej odpowiedni do Twojego pytania, polecam ten jeden, z tuż przed końcem:

ramy DI są niepotrzebne. W bardziej sztywnych środowiskach mają one wartość. W tak zwinnych środowiskach jak Ruby, a nie tak bardzo. Same wzory mogą być nadal stosowane, ale uważaj na wpadając w pułapkę myślenia, że ​​musisz mieć specjalne narzędzie do wszystkiego. Ruby to Play-Doh, pamiętaj! Zachowajmy w ten sposób .

HTH

Answer 2

Oto jeden IoC http://alexeypetrushin.github.com/micon

użyłem go jako kluczowy element mojego ram (nie Rails), można go zobaczyć tu pracuje - http://ruby-lang.info (ta strona zasilany z nim). I zaoszczędziło mi to dużo czasu i kodu, więc osobiście uważam IoC za bardzo użyteczny (w niektórych sytuacjach).

Systemy DI są niepotrzebne. W bardziej sztywnych środowiskach mają wartość. W zwinnych środowiskach takich jak Ruby, nie tak bardzo. Same wzory mogą wciąż mieć zastosowanie, ale strzeż się wpadnięcia w pułapkę myślenia, że ​​potrzebujesz specjalnego narzędzia do wszystkiego. Ruby to Play-Doh, pamiętaj! Zachowajmy to w ten sposób.

Patrzyłem dyskusja Jamis Buck, i zgadzam się i nie zgadzam wit go, oto dlaczego 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/: jest to kolejny, znacznie mniej uparty niż artykuł artykule James Buck. Najważniejsze jest to, że nie potrzebujesz zastrzyku zależności, ponieważ ruby ​​zapewnia mnóstwo dobrych alternatyw, które działają równie dobrze i które tak naprawdę nie istnieją w świecie Java.

Jedną z tych alternatyw jest mixins, która jest czymś, czego Java nie ma, a druga to możliwość nadpisania/przedefiniowania niemal wszystkiego w tym języku. Inne funkcje obejmują dynamiczne pisanie, gdzie zasadniczo można wysłać dowolną wiadomość do dowolnego obiektu, a jeśli zdarzy się, że zapewnia implementację dla tej wiadomości, rzeczy po prostu działają. Wszystkie te elementy współdziałają, aby usunąć większość potrzeb związanych z architekturą DI. Wzorzec projektowy jako taki jest nadal ważny również w Ruby i czasami po prostu ma sens, aby go użyć.

Inną kwestią dotyczącą DI, którą Alexey Petrushin powyżej również czyni, jest to, że zastrzyk zależności jest przede wszystkim wzorcem projektowym i że oprzyrządowanie jest drugorzędne, a przede wszystkim pozbywanie się żmudności pewnych rzeczy w Javie. W Ruby możesz trywialnie naśladować większość tego, co wiosną lub guice zrobi dla ciebie w Javie.Tak więc pełna struktura wtrysku zależności jest w zasadzie zbędna w Ruby.

To powiedziawszy, czasami posiadanie schematu DI jest miłe, ponieważ ostatecznie może zabrać trochę żmudnego okablowania. Nie mogę ręczyć za żadne konkretne struktury Ruby z Ruby, ale znam wiele projektów Ruby, które ostatecznie zostały przepisane w innym języku (nawet Java), ponieważ rzeczy w stylu playdoh sprawiają, że trudno jest je utrzymać/rozszerzyć. Podejrzewam, że ma to wiele wspólnego z programistami strzelającymi sobie w stopy z różnymi potężnymi funkcjami językowymi. Posiadanie schematu DI narzuca trochę struktury i idiomów, które mogą temu zapobiec.