Внедрение зависимостей, Scala и Spring

Question

Мне очень нравится концепция DI и слабосвязанной системы. Тем не менее, весной я обнаружил, что инструментов в лучшем случае не хватает. Например, трудно выполнить «рефакторинг», например, изменить имя бина, объявленного весной. Я новичок в весне, поэтому я бы что-то упустил. Нет проверки времени компиляции и т. Д.

Мой вопрос: почему мы хотим использовать XML для хранения конфигурации? IMO, вся идея Spring (часть IoC) состоит в том, чтобы навязать определенный творческий паттерн. В мире паттернов банды из четырех паттерны дизайна информативны. Spring (и другие DI), с другой стороны, обеспечивает очень предписанный способ подключения приложения к отдельным компонентам.

Я поместил Scala в заголовок так же, как я его изучаю. Как вы думаете, ребята, чтобы создать язык домена (что-то вроде библиотеки актеров) для приема зависимостей. Записывая фактический код для инъекций в самой Scala, вы получаете все полезности и инструменты, которые идут с ним. Несмотря на то, что разработчики приложений могли бы также обойти ваш фреймворк, я думаю, что его относительно легко стандартизировать, например, основной веб-сайт / приложение будет загружать только компоненты определенного шаблона.

Answer 1

Продолжаются дебаты, если 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!

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

Answer 2

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

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

Answer 3

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

Spring

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

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

XML был исходным выбором для spring , потому что это был де-факто стандарт Java-конфигурации, когда появилась платформа.В настоящее время аннотации - это популярный выбор.

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

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

---

DI и Scala

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

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

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

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

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

Answer 4

Я люблю концепцию DI и слабо спаренная система, много. Однако я найден инструмент весной не хватает Лучший. Например, это трудно сделать «рефакторинг», например изменить имя боб объявлен весной. я новый к весне, поэтому я бы пропал что-то. Нет времени компиляции проверить и т. д.

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

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

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

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

ApplicationContext - это не что иное, как фабрика / конструктор больших объектов. Это паттерн GoF.

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

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

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

Вы должны иметь в виду «инъекция».

Написание актуальный код впрыска в самой Scala, Вы получаете все вкусности и инструменты это идет с этим.

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

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

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

Но нет никаких причин, почему вы не должны попробовать это и посмотреть, сможете ли вы стать более успешным, чем Spring. Дайте нам знать, как вы делаете.

Answer 5

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

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

Answer 6

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

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

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

В Scala вы можете использовать шаблоны, такие как «Cake Patten», для реализации DI без фреймворка. Вы также можете использовать структурную типизацию для этого. Результат все еще грязный по сравнению с исходным кодом.

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

Answer 7

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