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

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

Продолжаются дискуссии о том, нужен ли 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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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