АВ
А как ты отдельный сервер под актуатор создаёшь?
server:
port: 8080
management:
server:
port: 9001
port: 8080
management:
server:
port: 9001
Size: a a a
2020 July 29
VS
Ох, ну тогда тебе дорога лазить по кишкам спринга, пытаясь придумать как туда вмешаться...
AS
Ну судя по твоим вопросам - ты не особо пытаешься разобраться, все твои вопросы можно найти в любой вводной статье про спринг, даже не открывая официальную документацию.
Либо ты просто не понимаешь что такое DI, несмотря на первоначальную декларацию
Либо ты просто не понимаешь что такое DI, несмотря на первоначальную декларацию
Вот у меня открыто несколько вводных статей.
1. https://www.vogella.com/tutorials/SpringDependencyInjection/article.html
Здесь в примере инжектят имплементации IWriter, у которых нет никаких зависимостей. Плюс используют
2. https://dzone.com/articles/how-dependency-injection-di-works-in-spring-java-a
Здесь опять же инжектят что-то, у чего нет своих зависимостей: инты, стринги. Плюс используют XML-файл, чего наверное тоже хотелось бы избежать.
3. https://www.geeksforgeeks.org/spring-dependency-injection-with-example/
Та же самая история.
Ну и по поводу слабой связности: в исходном коде и так вполне слабая связность, поскольку используется DI. Как спринг здесь что-то меняет?
1. https://www.vogella.com/tutorials/SpringDependencyInjection/article.html
Здесь в примере инжектят имплементации IWriter, у которых нет никаких зависимостей. Плюс используют
@Service. Это никак не помогло мой исходный завести под спрингом.2. https://dzone.com/articles/how-dependency-injection-di-works-in-spring-java-a
Здесь опять же инжектят что-то, у чего нет своих зависимостей: инты, стринги. Плюс используют XML-файл, чего наверное тоже хотелось бы избежать.
3. https://www.geeksforgeeks.org/spring-dependency-injection-with-example/
Та же самая история.
Ну и по поводу слабой связности: в исходном коде и так вполне слабая связность, поскольку используется DI. Как спринг здесь что-то меняет?
VS
Вот у меня открыто несколько вводных статей.
1. https://www.vogella.com/tutorials/SpringDependencyInjection/article.html
Здесь в примере инжектят имплементации IWriter, у которых нет никаких зависимостей. Плюс используют
2. https://dzone.com/articles/how-dependency-injection-di-works-in-spring-java-a
Здесь опять же инжектят что-то, у чего нет своих зависимостей: инты, стринги. Плюс используют XML-файл, чего наверное тоже хотелось бы избежать.
3. https://www.geeksforgeeks.org/spring-dependency-injection-with-example/
Та же самая история.
Ну и по поводу слабой связности: в исходном коде и так вполне слабая связность, поскольку используется DI. Как спринг здесь что-то меняет?
1. https://www.vogella.com/tutorials/SpringDependencyInjection/article.html
Здесь в примере инжектят имплементации IWriter, у которых нет никаких зависимостей. Плюс используют
@Service. Это никак не помогло мой исходный завести под спрингом.2. https://dzone.com/articles/how-dependency-injection-di-works-in-spring-java-a
Здесь опять же инжектят что-то, у чего нет своих зависимостей: инты, стринги. Плюс используют XML-файл, чего наверное тоже хотелось бы избежать.
3. https://www.geeksforgeeks.org/spring-dependency-injection-with-example/
Та же самая история.
Ну и по поводу слабой связности: в исходном коде и так вполне слабая связность, поскольку используется DI. Как спринг здесь что-то меняет?
в исходном коде у тебя через new все создается, где там di?
AS
в исходном коде у тебя через new все создается, где там di?
Так в ручном DI так и происходит. Есть классы, которые принимают зависимости через конструктор, и есть composition root, который связывает конкретные имплементации через кучу new. Это же основы. И меня же ещё обвиняют в том, что я плохо DI понимаю.
Но суть вообще не в этом. Просто я потратил полтора часа на то, чтобы найти какую-то понятную информацию о спринге, и понял в итоге, что проще и быстрее будет найти специализированный чат и задать живым людям свой вопрос. И в принципе частично мне на него ответили, так что не понимаю, в чём проблема.
Но суть вообще не в этом. Просто я потратил полтора часа на то, чтобы найти какую-то понятную информацию о спринге, и понял в итоге, что проще и быстрее будет найти специализированный чат и задать живым людям свой вопрос. И в принципе частично мне на него ответили, так что не понимаю, в чём проблема.
VS
окей, если принимать во внимание что это типа ручной di - хорошо. но инверсии контроля у тебя все равно нет, т.к. нет контейнера с бинами. и ты пытаешься натянуть свой ручной di на сприниговый контекст. так не покатит. тебе надо просто изучить, как заставить спринг складывать бины в твой контейнер
AS
окей, если принимать во внимание что это типа ручной di - хорошо. но инверсии контроля у тебя все равно нет, т.к. нет контейнера с бинами. и ты пытаешься натянуть свой ручной di на сприниговый контекст. так не покатит. тебе надо просто изучить, как заставить спринг складывать бины в твой контейнер
Ну я стараюсь минимизировать зависимость кода от самого спринга, как все советуют, чтобы все аннотации были только в руте, но такое ощущение, будто его дизайн этому сопротивляется
VS
Ну я стараюсь минимизировать зависимость кода от самого спринга, как все советуют, чтобы все аннотации были только в руте, но такое ощущение, будто его дизайн этому сопротивляется
ну, к сожалению, если ты берешь большой фреймворк - то ты берешь его раз и навсегда. минимизировать зависимость от него не получится, потому что по факту это каркас твоего приложения.
AS
Ну я так понимаю, в какой-то мере это всё-таки возможно, потому что вот что люди пишут:
since you have a \@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.
since you have a \@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.
БТ
Ну я так понимаю, в какой-то мере это всё-таки возможно, потому что вот что люди пишут:
since you have a \@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.
since you have a \@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.@Configuration class, why not define your beans in there with \@Bean and remove all the \@Autowired and \@Component annotations? When you use \@Autowired and \@Component annotations, you make your code depend on Spring. If you define your beans with \@Bean, your Spring configuration is separate from your code. It is not so clean letting your code depend on Spring. Imagine you create a library, then you force users of your library to use the same dependency injection framework while they may already be using another one.
а как вайрить то без @Autowired? Вручную из контекста доставать?
AS
а как вайрить то без @Autowired? Вручную из контекста доставать?
@Autowired вроде не обязателен, если конструктор одинAE
а как вайрить то без @Autowired? Вручную из контекста доставать?
Constructor injection уже лет 5 совет для автовайринга по умолчанию
VA
Ну я стараюсь минимизировать зависимость кода от самого спринга, как все советуют, чтобы все аннотации были только в руте, но такое ощущение, будто его дизайн этому сопротивляется
Ну спринг это фреймворк, как озвучено выше. Вы можете использовать его и как библиотеку, взять всякие REST/JDBC/RabbitMQ templat'ы и использовать их без остальных зависимостей спринга вообще, к примеру. Но если вы хотите механизм внедрения зависимостей, то тут вы либо берете спринг как фреймворк своего приложения, либо берете библиотеку, реализующую JSR330. Возводить вокруг спринга карго-культ, как по мне, самая плохая идея. Годная только для изучения самого спринга.
БТ
Constructor injection уже лет 5 совет для автовайринга по умолчанию
хм, ну я всё равно над конструктором автовайред пишу
AE
хм, ну я всё равно над конструктором автовайред пишу
Не надо
БТ
ну это как @Override, как бы не обязательно, но всё же
VA
ну это как @Override, как бы не обязательно, но всё же
Оверрайд как раз обязательно 😁
БТ
Оверрайд как раз обязательно 😁
с каких пор?
БТ
ты не можешь переопределить метод без @Override?