Ну это совсем монолит пуре ява уж))

что подразумевается под монолит?

spring приложения и так монолитны

spring приложения и так монолитны

Физически да, а логически нет.

почему логически нет?

То что ди в принципе позволяет инжектить бины с дефолт конструкторами. Без знаниях их реализации

почему логически нет?

Потому что спринг приложения больше похожи на кучу микросервисов в общей оболочку.

То что ди в принципе позволяет инжектить бины с дефолт конструкторами. Без знаниях их реализации

Ну, это вопросы оформления.

так кажется потому что не видно где Spring делает new, т.е. он просто скрывает часть работы которая в другом случае легла бы на самого программиста

так кажется потому что не видно где Spring делает new, т.е. он просто скрывает часть работы которая в другом случае легла бы на самого программиста

Да, и это прекрасно. Ты убираешь шелуху, концентрируясь на задачах.

да но при этом ты получаешь минусы в других местах

да но при этом ты получаешь минусы в других местах

?

уже обсуждали, циклические зависимости, на них буквально несколько лет назад толкал сам спринг

куча зависимостей в классе, отсутствие вертикального проектирования классов

уже обсуждали, циклические зависимости, на них буквально несколько лет назад толкал сам спринг

так если ты юзаешь инжект через конструктор их и не будет

у тебя приложение не поднимется

вертикальное проектирование? что имеешь в виду

я имею ввиду

что сейчас пишут 50 сервисов

которые находятся на одном

уровне в иерархии классов

и затем инжектят их друг в друга

ии?

Поэтому нужно использовать акку) Азаза

и это приводит к каше

???

Поэтому нужно использовать акку) Азаза

???

и затем инжектят их друг в друга

Контейнер это разрулит. Не?

???

Там нет инжекта, так что ты не запутаешься)

а код кто твой разрулит?

25 сервисов инжектят в другой

Если бы они были на одном уровне, то это были бы циклические зависимости.

и пилят 25 методов

которые используют один-два из заинжектенных классов

Это проблема проектирования, а не IOC контейнера

согласен

IOC контейнер приводит к таким проблемам

25 зависимостей - декомпозировать!

IOC контейнер приводит к таким проблемам

А наличие мозга решает эти проблемы.

госпади ну глянь

любой проект

на спринге

в любой компании

везде тупые по ходу

работают

а ты во всех компаниях был?

одни идиоты вокруг

на всех проектах сразу?

я видел несколько проектов

херасе топарь

хватит

так

писать

заебали

пишите

все

слова

в

одном

сообщении

еще одно слово и я баню

Паттерн фасад. Проще некуда. Реализуешь. И ижектишь только его.

Паттерн фасад. Проще некуда. Реализуешь. И ижектишь только его.

дристня

видел фасад на 5к строк

Паттерн фасад. Проще некуда. Реализуешь. И ижектишь только его.

Spring программист напишет @Autowired и хер положит на твой паттерн

еще одно слово и я баню

Блин, у меня горит от таких персонажей.

ERROR: S client not available

Проектированием сервисов и их зависимостей занимается разработчик, а IOC контейнер задает единый жизненный цикл для всего этого.

эт получает не индусы плохой код пишут, а джава - говно?

Spring программист напишет @Autowired и хер положит на твой паттерн

Слушай, идиоты есть везде. Ты считаешь, что если прогер будет писать явно, то будет лучше? Он вообще ничего не напишет.

эт получает не индусы плохой код пишут, а джава - говно?

Ну да)

хэх

дристня

Ну нет. Чот ты какойто максималист))

Джава говно)

и сисярп тогда тоже

и кресты

и другие языки

Проектированием сервисов и их зависимостей занимается разработчик, а IOC контейнер задает единый жизненный цикл для всего этого.

IOC контейнер принуждает программиста писать код в рамках своего API которое фактически принуждает программиста где-то что то упрощать и не додумывать надеясь на фреймворк, потому что почему бы не написать @GET и не думать что там делает Spring это же так просто

и сисярп тогда тоже

Ну да)

Я сегодня с js ебался и понял, что динамика - это пиздец.

IOC контейнер принуждает программиста писать код в рамках своего API которое фактически принуждает программиста где-то что то упрощать и не додумывать надеясь на фреймворк, потому что почему бы не написать @GET и не думать что там делает Spring это же так просто

короче я понял, надо все своими силами достигатЬ!

Ну вот конкретный пример - GET в JAX-RS (или GetMapping в Spring). Что не так?

без пратеинов и химии!

я поясню свой коммент, у Spring есть 3 аннотации для инжекта, это @Resource, @Inject, @Autowired, вопрос зачем их столько?

подумаешь прогресс нам дал спринг

IOC контейнер принуждает программиста писать код в рамках своего API которое фактически принуждает программиста где-то что то упрощать и не додумывать надеясь на фреймворк, потому что почему бы не написать @GET и не думать что там делает Spring это же так просто

Да, это позволяет покупать обезьянок с часовой ставной x, а не 100x.

давайте в прошлое вернемся

я поясню свой коммент, у Spring есть 3 аннотации для инжекта, это @Resource, @Inject, @Autowired, вопрос зачем их столько?

Они разные ж поди

Как в ее

Еджб и инжект

я не в курсе в чем они разные, возможно @Resource еще чем то отличается, но @Autowired и @Inject это синонимы

Так как уже часть работы сделана. Да, обезьянки могут молотком не гвозди забивать, а голову расшибить. Ну, бывает.

Нет. Автовайред ди через геттер/сеттер. А инжект через конструктор. Вроде

я не призываю вернуться в прошлое, я лишь указываю на то что DI не всегда хорошо и что неправильное использование DI приводит к совершенно другим проблемам, которые возможно не возникли бы при кодинге в pure Java

нет конечно все они работают везде

Autowired - ищет по типу и дженерику и по названию. Можно указать, является ли бин кандидатом для автоваринга или нет

Проблем решает больше чем создает.

Поэтому его все любят