Инъекция зависимостей, Scala и Spring

Ответ 1

Там хорошая статья об использовании Scala вместе с Spring и Hibernate здесь.

О вашем вопросе: вы действительно можете использовать аннотации. Это имеет некоторые преимущества. XML, в свою очередь, хорош тем, что вам не нужно перекомпилировать файлы, содержащие ваши инжекционные конфиги.

Ответ 2

Продолжается дискуссия, если Scala требуется DI. Существует несколько способов "сделать это самостоятельно", но часто эта простая настройка достаточно:

//the class that needs injection
abstract class Foo {
  val injectMe:String
  def hello = println("Hello " + injectMe)
}

//The "binding module"
trait Binder {
  def createFooInstance:Foo
}

object BinderImpl extends Binder {
  trait FooInjector {
    val injectMe = "DI!"   
  }

  def createFooInstance:Foo = new Foo with FooInjector
}

//The client
val binder:Binder = getSomehowTheRightBinderImpl  //one way would be a ServiceLoader
val foo = binder.createFooInstance
foo.hello
//--> Hello DI!

Для других версий посмотрите здесь, например.

Ответ 3

Мне нравится концепция DI и свободно связанной системы, много. Тем не менее, я найденный инструмент в Spring отсутствует на Лучший. Например, это трудно сделать "рефакторинг", например. изменить имя из bean, объявленного в Spring. я новенький до Spring, поэтому мне не хватало что нибудь. Нет времени компиляции проверить и т.д.

Вам нужна умная среда IDE. IntelliJ из JetBrains позволяет рефакторинг, переименование и т.д. С полным пониманием вашей конфигурации Spring и ваших классов.

Мой вопрос - почему мы хотим использовать XML для хранения конфигурации?

Почему бы и нет? Вы должны положить его где-нибудь. Теперь у вас есть выбор: XML или аннотации.

ММО, вся идея Spring (часть IoC) для создания определенного шаблона создания. В мире банд-оф-четырех моделей, шаблоны проектирования являются информативными.

ApplicationContext - это не что иное, как большой объект factory/builder. Это шаблон GoF.

Spring (и другие ДИ) с другой стороны рука, обеспечивает очень предписанный способ, как приложение должно быть подключено с отдельными компонентами.

GoF еще более предписывает: вы должны создавать его в объекты или экстернализировать его в конфигурации. Spring экстернализирует его.

Я поместил Scala в заголовок как я его изучаю. Как вы, ребята? подумайте, чтобы создать язык домена (что-то вроде библиотеки актеров) для зависимость от употребления.

Вы должны означать "инъекцию".

Написание фактический код инъекции в Scala сам, вы получаете все лакомства и инструменты который приходит с ним.

Не вижу, что это купит меня сверх того, что мне дает Spring.

Несмотря на то, разработчики приложений могли бы также обойти ваши рамки, я бы подумал он относительно прост в стандарте, такой поскольку основной веб-сайт/приложение будет загружать компоненты определенного шаблона.

Извините, я не покупаю вашу идею. Я бы предпочел использовать Spring.

Но нет причин, по которым вы не должны пытаться это сделать, и посмотреть, сможете ли вы стать более успешными, чем Spring. Сообщите нам, как вы это делаете.

Ответ 4

В java существуют разные подходы к DI, и не все они обязательно основаны на xml.

Spring

Spring обеспечивает полную реализацию контейнера и интеграцию со многими службами (транзакциями, jndi, persistence, datasources, mvc, scheduling,...) и может быть лучше определен с использованием аннотаций java.

Его популярность связана с количеством сервисов, которые интегрируется в платформу, кроме DI (многие используют ее как альтернативу Java EE, которая на самом деле соответствует пути spring, начиная с 5-й версии).

XML был оригинальным выбором для spring, поскольку он был стандартным стандартом java-конфигурации, когда была создана инфраструктура. Аннотации - популярный выбор прямо сейчас.

Как личная сторона, концептуально я не являюсь огромным поклонником DI, основанной на аннотациях, для меня это создает плотную связь конфигурации и кода, тем самым побеждая исходную цель DI.

Существуют и другие реализации DI, которые поддерживают альтернативную конфигурационную декларацию: AFAIK Google Guice является одним из тех, который позволяет также осуществлять программную конфигурацию.

DI и Scala

Существуют альтернативные решения для DI в scala, помимо использования известных java-фреймворков (которые, насколько я знаю, достаточно хорошо интегрированы).

Для меня наиболее интересными, которые поддерживают знакомый подход к java, является subcut.

Он поражает хороший баланс между google guice и одним из наиболее известных шаблонов DI, разрешенных специфическим дизайном языка scala: Рисунок торта. Вы можете найти много сообщений в блоге и видео об этом шаблоне с google search.

Другое решение, доступное в scala, использует Reader Monad, который уже является установленным шаблоном для динамической конфигурации в Haskell и объясняется довольно хорошо в этом видео с NE scala Symposium 2012 и в это видео и связанные с ним слайды.

Последний выбор связан с предупреждением о том, что он предполагает достойный уровень понимания концепции Монад в целом и в scala, и часто вызывает некоторые споры вокруг его концептуальной сложности и практической полезности. Этот связанный поток на scala -debate ML может быть весьма полезен, чтобы лучше справиться с этим вопросом.

Ответ 5

Я не могу прокомментировать scala, но DI помогает принудительно отключить связь. Это значительно упрощает реорганизацию больших приложений soooo. Если вам не нравится компонент, просто замените его. Нужна другая реализация для конкретной среды, просто подключите новый компонент.

Ответ 6

Я согласен! Для меня он, как большинство людей использует Spring, является легкой версией ада.

Когда вы смотрите на стандартный сведенный код, есть интерфейсы повсюду, и вы никогда не знаете, какой класс используется для реализации интерфейса. Вы должны изучить какую-то фантастическую конфигурацию, чтобы это выяснить. Легко читается = нет. Чтобы сделать этот код доступным для серфинга, вам нужна очень продвинутая среда разработки, например Intelly J.

Как мы оказались в этом беспорядке? Я обвиняю автоматическое модульное тестирование! Если вы хотите подключать mocks к каждому классу, у вас не может быть зависимостей. Если бы это было не для модульного тестирования, мы могли бы сделать так же хорошо, как без муфты, так как мы не хотим, чтобы клиент заменил отдельные классы волей-неволей в наших банках.

В Scala вы можете использовать шаблоны, такие как "Cake Patten" для реализации DI без рамки. Для этого вы также можете использовать структурную типизацию. Результат по-прежнему беспорядочен по сравнению с исходным кодом.

Лично я думаю, что следует рассмотреть возможность автоматического тестирования модулей вместо классов, чтобы избежать этого беспорядка, и использовать DI для развязки целых модулей. Эта стратегия по определению не является модульным тестированием. Я думаю, что большая часть логики заключается в фактических связях между классами, поэтому ИМХО будет больше полезен для тестирования модулей, чем модульное тестирование.

Ответ 7

Я не могу согласиться с тем, что XML является проблемой в Java и Spring: Я использую Spring и Java широко, без большого количества XML, потому что большинство настроек выполняется с аннотациями (тип и имя - мощный контракт) - это выглядит очень хорошо. Только для 10% случаев я использую XML, потому что это проще сделать в XML, чем специальное решение для кода с фабриками/новыми классами/аннотациями. Этот подход был вдохновлен Guice и Spring из 3.0 реализует его как JSR-330 (но даже я использую Spring 2,5 с Spring factory, настроенный с аннотациями JSR-330 вместо стандартного spring -специфического @Autowired).

Вероятно, scala может обеспечить лучший синтаксис для разработки в стиле DI, и я сейчас смотрю на него (заостренный шаблон Cake).