Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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-паттерн заставляет плодить слишком много лишних сущностей (трейтов) для каждого компонента, у меня был опыт его использования в одном средних размеров проекте, удовольствия он приносит мало.
Имплиситы — сами по себе не делают 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 через конструктор. Считаю что в случае микросервисной архитектуры например, использовать какую-то тулу это явный оверинжиниринг.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Dependency Injection с проверкой корректности на Scala средствами языка