Библиотеки инъекций на основе Ruby

Question

Я изучал некоторые библиотеки инъекций на основе Ruby. В частности, я проверил Needle и Copland. Они были вокруг довольно долго, но не много обычаев.

Каковы некоторые из плюсов и минусов использования этих двух библиотек? Кажется, что многие библиотеки/фреймворки могут хорошо использовать эти две библиотеки, например. Merb/Datamapper's Hook.

Answer 1

Jamis Buck, который написал Copland and Needle, posted here о игле, инъекции зависимостей и их полезности в мире Ruby.

Это долго, но стоит читать, но в случае, если вы хотите, чтобы один абзац наиболее подходящий к вашему вопросу, я хотел бы предложить это одно, от только до конца:

рамки DI излишни. В более жестких средах они имеют ценность. В гибких средах, таких как Ruby, а не столько. Сами образцы могут быть по-прежнему применимы, но остерегайтесь , попадающих в ловушку, думая, что вы нуждаетесь в специальном инструменте для всего. Ruby - Play-Doh, помните! Итак, держим .

НТН

Answer 2

Вот еще один IoC http://alexeypetrushin.github.com/micon

Я использовал его в качестве одного из основных компонентов моего веб-рамки (не Rails), Вы можете увидеть его здесь работать - http://ruby-lang.info (этот сайт работает с ним). И это спасло меня много времени и кода, поэтому я лично считаю IoC очень полезным (в некоторых ситуациях).

Основы DI не нужны. В более жестких условиях они имеют ценность. В гибких средах, таких как Ruby, не так много. Сами образцы могут по-прежнему применяться, но остерегайтесь попадания в ловушку мысли, что вам нужен специальный инструмент для всего. Помните, Ruby - Play-Doh! Давайте так и будем.

Я наблюдал разговор о Jamis Buck, и я согласен и не согласен остроумие его, вот почему 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/: это еще один, гораздо менее самоуверенным статья, чем статьи Джеймс Бак. Нижняя линия заключается в том, что вам не нужна инъекция зависимостей, потому что Ruby предоставляет множество хороших альтернатив, которые работают так же хорошо и которые на самом деле не существуют в мире Java.

Одна из этих альтернатив - это mixins, чего нет у Java, а другая - возможность переопределить/переопределить практически что-либо на языке. Другие функции включают динамическую типизацию, в которой вы можете отправлять любое сообщение любому объекту, и если это произойдет, чтобы обеспечить реализацию этого сообщения, все будет работать. Все эти вещи работают вместе, чтобы устранить большую часть потребности в инфраструктуре DI. Шаблон проектирования как таковой по-прежнему действует и в Ruby, и иногда имеет смысл использовать его.

Еще один момент, касающийся того, что Алексей Петрушин также делает, заключается в том, что инъекция зависимостей - это, прежде всего, шаблон дизайна и что оснастка является вторичной и в основном заключается в том, чтобы избавиться от утомительности некоторых вещей на Java. В рубине вы можете тривиально эмулировать большую часть того, что весна или ухаживает для вас на Java.Таким образом, полномасштабная структура инъекций зависимостей в Ruby существенно избыточна.

Это, как говорится, иногда с каркасом DI является хорошим, так как в конечном итоге это может забрать часть утомительности электромонтажа. Я не могу ручаться за любые Ruby-специфические рамки DI, но я знаю много проектов Ruby, которые в конечном итоге были переписаны на другом языке (даже Java), потому что характер игры в стиле playdo создает трудности для поддержания/расширения. Я подозреваю, что это имеет много общего с разработчиками, стреляющими в ногу с различными мощными языковыми функциями. Наличие рамок DI накладывает немного структуры и идиомы, которые могут помочь предотвратить это.