Pull to refresh

Comments 6

Непонятна необходимость DI фреймворков в Scala. Трейты, имплиситы, ридер-монады чем не угодили? Play Framewor стал использовать Google Guice, обосновывая это тем, что мол в Scala столько встроенных возможностей для DI, что сообщество не может договориться, что лучше, поэтому мы не будем использовать ни одну из них и пойдем Java-way. Что со Scala не так?
Трейты — видимо речь о cake-паттерне?
Cake-паттерн заставляет плодить слишком много лишних сущностей (трейтов) для каждого компонента, у меня был опыт его использования в одном средних размеров проекте, удовольствия он приносит мало.
Имплиситы — сами по себе не делают DI, поскольку остается важным порядок их объявления.
Reader-monad — это можно сказать родственная идея. Но там тоже нужно учитывать порядок инжекта (поправьте кстати меня, если я недопонял концепцию), есть проблемы с множественными зависимостями. Ну и в целом, скорее всего для них захочется притянуть scalaz, который далеко не всем по душе.

А вообще конечно же можно и без них, особенно если у вас небольшие проекты.
А в java-мире до сих пор средствами языка выкрутиться было нельзя (а теперь, с default-реализациями теперь тоже можно делать cake), по этому все просто берут библиотеку, использующую reflection — то есть guice или spring — и не парятся.
Cake-паттерн заставляет плодить слишком много лишних сущностей (трейтов) для каждого компонента

Зачем для каждого? Можно для групп компонентов: Thin cake pattern. Или все зависимости объединить в один «контекст»

Имплиситы — сами по себе не делают DI, поскольку остается важным порядок их объявления.

Не понял мысль? Какой такой порядок? Проблема имплиситов такая же как и у внедрения через конструктор — если много, то неудобно. Выход как и в предыдущем случае: композиция зависимостей в более крупные объекты (опять получается что-то типа контекста)

Единственное оправдание использования DI фреймворка пока вижу только для случаев «инжектим всё во всё на всякий случай, потом разберемся» и «мы в java так привыкли»
Не понял мысль? Какой такой порядок?

Имплиситы это более удобный способ передачи параметров и не более. С помощью него можно сделать ручной DI, только чуть меньшим количеством знаков.

Следовательно, вы можете сделать так:
case class A(v: Int)

case class B(implicit a: A)

case class C(implicit b: B)


implicit val a = A(10)

implicit val b = B()

val c = C()


Но вот так уже не можете, так как получите ошибку компиляции:
implicit val b = B()

implicit val a = A(10)

val c = C()

поскольку в момент объявления b скоуп не содержит никакого имплиситного значения типа A.

И этим отличается ручной DI от автоматизированного — когда у вас пара классов — создавать их явно очень здравая идея, но если вы создаете в коде кучу компонент, следить за порядком их объявления и создания может стать утомительно.
Зачем для каждого? Можно для групп компонентов: Thin cake pattern. Или все зависимости объединить в один «контекст»

Здесь мысль в том, чтобы вместо большого кейка, делать небольшие модули, которые собирать вручную, и собирать кейк уже из них. Мысль в каком-то смысле здравая.

Я в общем и не выступаю против ручного DI через конструктор. Считаю что в случае микросервисной архитектуры например, использовать какую-то тулу это явный оверинжиниринг.
UFO just landed and posted this here
Смотрел на него, но видимо там тоже речь о макросах, да и про проблему циклических зависимостей ничего не написано. Мне было интересно просто попробовать другой взгляд.
Sign up to leave a comment.

Articles