почему все? я знаю куча крутых спецов которые открещиваются от спринга

Это как с C++. Нужно ограничивать возможности)

Ну так как они решают те проблемы, что решает спринг - эти твои крутые спецы?

Фабриками синглтонов

они не видят в new проблемы, они продумывают иерархию классов и все ок

синглтоны не юзают

это же антипаттерн

Фабриками синглтонами тогда

они не видят в new проблемы, они продумывают иерархию классов и все ок

Т.е. решают одну и ту же проблему каждый раз?

В смысле? У тебя одна и та же иерархия классов под каждый проект?

Писать бойлерплейт вручную еще не значит продумывать иерархию

это же антипаттерн

У тебя страшный котик на авке

Это просто траншеи лопатой выгребать и утверждать что ты магистр штыковых лопат

Писать бойлерплейт вручную еще не значит продумывать иерархию

где я писал что они пишут бойлерплейт? я вижу сотни строк бойлерплейта в Spring проектах, и классы по сотни строк

В смысле? У тебя одна и та же иерархия классов под каждый проект?

Кроме продумывания иерархии нужно это ещё как то реализовать. А вот здесь начивается решение одной и той же проблемы.

Спринг не решает проблему иерархии классов за тебя, но он решает проблему связывания этих классов.

Иерархию нужно продумывать в обоих случаях.

Ладно. А мне вот понравился доклад гупты. Фаас в принципе интересен. Амазон четкие посаны. Провда походу это все дорого шопипец выходит. Но коасиво вынлядит

Он решает эту проблему добавляя новую, и вот тут задумаешься в следующий раз нужно ли тебе такое решение или нет

Ну так какую проблему-то он создает?

На докере это дешевле выйдет чем на амазоне

Этот их сервис рест апи. Лямбда. Все платное.

На докере это дешевле выйдет чем на амазоне

А ты пробовал докер в проде?)проблем не было?)

Он решает эту проблему добавляя новую, и вот тут задумаешься в следующий раз нужно ли тебе такое решение или нет

Какую он проблему добавляет, если ты продумал иерархию?

На докере это дешевле выйдет чем на амазоне

Эм?

А ты пробовал докер в проде?)проблем не было?)

Только в дев среде. Прод на реал железе

Как можно сравнивать колбасу и ядерный реактор?

Только в дев среде. Прод на реал железе

Так вот докер то ещё гавно)

Ну так какую проблему-то он создает?

циклические зависимости, отсутствие продуманной иерархии(программист начинает тупо клепать @Service классы), спорные аннотации(Component,Service,Repository)(Autowired, Resource, Inject), куча кода скрытого от программиста который периодически валится в проде, куча легаси кода в самом спринге с которым тяжело работать, куча либ навязанных всей инфраструктурой спринга и по сути ненужных(Spring Data JPA), я бы мог еще куче всего перечислять

циклические зависимости, отсутствие продуманной иерархии(программист начинает тупо клепать @Service классы), спорные аннотации(Component,Service,Repository)(Autowired, Resource, Inject), куча кода скрытого от программиста который периодически валится в проде, куча легаси кода в самом спринге с которым тяжело работать, куча либ навязанных всей инфраструктурой спринга и по сути ненужных(Spring Data JPA), я бы мог еще куче всего перечислять

Ничего страшного в этом нет, бизнеслогику нужно кому то писать

Тебе уже пояснили, что спринг за тебя граф зависимостей не напишет

А ты пробовал докер в проде?)проблем не было?)

да, проблемы как всегда

циклические зависимости, отсутствие продуманной иерархии(программист начинает тупо клепать @Service классы), спорные аннотации(Component,Service,Repository)(Autowired, Resource, Inject), куча кода скрытого от программиста который периодически валится в проде, куча легаси кода в самом спринге с которым тяжело работать, куча либ навязанных всей инфраструктурой спринга и по сути ненужных(Spring Data JPA), я бы мог еще куче всего перечислять

Так мы говорим об опытных программерах или неопр=ытных?

Ничего страшного в этом нет, бизнеслогику нужно кому то писать

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

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

Как твои опытные программеры связывают классы?

Да, ты определенно не получишь циклические зависимости если всюду будешь пихать новые инстансы

Как твои опытные программеры связывают классы?

new Dao(new DataSource(...));

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

Ну не, в моих проектах не так много монад

Айлолд в каждый сервис разные инстансы датасоуса

Да, ты определенно не получишь циклические зависимости если всюду будешь пихать новые инстансы

почему бы и не пихать инстансы в языке который создан для создания объектов

new Dao(new DataSource(...));

Т.е. они не пользуются удобным инструментом, а пишут это?

а если вы ребята посмотрите сколько всего JPA создает который использует каждый

почему бы и не пихать инстансы в языке который создан для создания объектов

Потому что это не читаемо.

то навсегда перестанете думать о объектах

а если вы ребята посмотрите сколько всего JPA создает который использует каждый

А зачем?

А что плохого в циклических зависимостях?)

Так вот докер то ещё гавно)

А вот лямбда эта. То что в контейнере просто будет тупить. В лямбде тебя посадит на штуку баксов. Аиазон то любой нептимальный код запустит.

А что плохого в циклических зависимостях?)

чем плох плохой код? как посмотреть

для некоторых любой код хорош

почему бы и не пихать инстансы в языке который создан для создания объектов

Ты спрашиваешь почему нельзя пихать новые инстансы датасоуса в каждый сервис?

В циклических зависимостях нет ничего плохого, кроме того что они нерешаемы и контекст не собирается. А так все хорошо

чем плох плохой код? как посмотреть

Ну я т не так написал, не утрируй

то навсегда перестанете думать о объектах

Слушай, плохой программист не напишет приложение как на спринге, так и без спринга. А опытный напишет и так, и так. Так почему бы не пользоваться спрингом?

Слушай, плохой программист не напишет приложение как на спринге, так и без спринга. А опытный напишет и так, и так. Так почему бы не пользоваться спрингом?

Много рантаима)))

Слушай, плохой программист не напишет приложение как на спринге, так и без спринга. А опытный напишет и так, и так. Так почему бы не пользоваться спрингом?

мой опыт говорит о том что хороший программист не будет юзать как минимум 50% возможностей спринга потому что они ему тупо не нужны или не устроят его, все что нужно от спринга по сути это @Inject на конструктор, все остальное это уже такое себе удовольствие, может и есть исключения когда нужно инжектить в сеттер но их согласно моему опыту крайне мало, но еще буквально недавно в доках спринга советовали @Autowired вешать на поля в классах(правда быстро одумались и стали писать что это вредно)

мой опыт говорит о том что хороший программист не будет юзать как минимум 50% возможностей спринга потому что они ему тупо не нужны или не устроят его, все что нужно от спринга по сути это @Inject на конструктор, все остальное это уже такое себе удовольствие, может и есть исключения когда нужно инжектить в сеттер но их согласно моему опыту крайне мало, но еще буквально недавно в доках спринга советовали @Autowired вешать на поля в классах(правда быстро одумались и стали писать что это вредно)

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

А этот динамодб от амазона имеет что то уровня люцента для полнотекстового поиске? Например я 10 гб залью базу. Он индексы постоит, а для рест апи еще и закеширует? То есть 10 т запросов к апи по кешу отработают?

Вот например я кладр на шпринге с люцентом делал. Поиск по 5 гб базе гдето 0,3 сек

Амазон это закеширует и будет 0,001 с без запросов к бд?

пропустил начало истории, но нахрена тебе 0.001 ?

Важнее кеш

Если 19к клиентов

Чтоб не дергал люцент

А по кешу отрабатывал

Но там и индекс люцента под 500 мб

ERROR: S client not available

Простой пример де. Кладр

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

Поиск по составному ключу текстовому

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

нет, если используешь Spring, делай это с умом либо не используй вовсе, многие думают что Spring такой охуенный фреймворк который автоматом все решает за программиста и начинают клепать Autowired направо и налево, но в нормальном проекте Spring должен быть незаметен как например Guice, который просто как рабочая лошадка делает свою работу, Spring же пытается залезть во все аспекты твоего проекта со своим лучшим решением которое на деле часто работает не так как ожидаешь 1. Spring своим вольным обращением с аннотациями смущает новичков которые пишут на спринге, люди не понимают как использовать DI а спринг только ухудшает их положение. В итоге люди забывают о том что в Java поощрается глубокое проектирование структуры классов, не дефолтные уровни Controller/Repository/Service, а декомпозиция например уровня Service на более мелкие уровни. Но Spring своей аннотацией Service как бы указывает людям дескать вот у вас обязан этот уровень быть 2. Некоторые аннотации не работают, например я натыкался на нерабочую аннотацию @Valid 3. Работа некоторых аннотаций не описана полностью в доках, например @ModelAttribute, люди банально не знают что она делает Короче забей, это мое мнение основанное на моем опыте, я знаю еще людей и достаточно хороших профессионлов(для меня), которые и на Java One выступали(не Егор) и которые пишут серьезный софт в банковской среде(т.е. тот самый энтерпрайз) и которые не хотят и не будут юзать Spring. Как то так

нет, если используешь Spring, делай это с умом либо не используй вовсе, многие думают что Spring такой охуенный фреймворк который автоматом все решает за программиста и начинают клепать Autowired направо и налево, но в нормальном проекте Spring должен быть незаметен как например Guice, который просто как рабочая лошадка делает свою работу, Spring же пытается залезть во все аспекты твоего проекта со своим лучшим решением которое на деле часто работает не так как ожидаешь 1. Spring своим вольным обращением с аннотациями смущает новичков которые пишут на спринге, люди не понимают как использовать DI а спринг только ухудшает их положение. В итоге люди забывают о том что в Java поощрается глубокое проектирование структуры классов, не дефолтные уровни Controller/Repository/Service, а декомпозиция например уровня Service на более мелкие уровни. Но Spring своей аннотацией Service как бы указывает людям дескать вот у вас обязан этот уровень быть 2. Некоторые аннотации не работают, например я натыкался на нерабочую аннотацию @Valid 3. Работа некоторых аннотаций не описана полностью в доках, например @ModelAttribute, люди банально не знают что она делает Короче забей, это мое мнение основанное на моем опыте, я знаю еще людей и достаточно хороших профессионлов(для меня), которые и на Java One выступали(не Егор) и которые пишут серьезный софт в банковской среде(т.е. тот самый энтерпрайз) и которые не хотят и не будут юзать Spring. Как то так

Как у тебя пальцы не устали это писать? :)

я с компа

))

писать серьезный софт в банковской сфере не значит писать хороший код

это вообще две несвязанные вещи

а по поводу спринг лезет - он просто предлагает инструменты, тебе решать - использовать их или нет

писать серьезный софт в банковской сфере не значит писать хороший код

Клиент альфабанка кусок кала )))

а по поводу спринг лезет - он просто предлагает инструменты, тебе решать - использовать их или нет

мне нравится либа Spring JDBC но я не могу притянуть ее в проект потому что она тянет spring core

вай?

Так мы же про бэкенд

вай?

SPRING

жаловаться на либу, которая была под экосистему написана

Так мы же про бэкенд

У каждого он свой

мне нравится движок порше, почему я обязан покупать целый автомобиль?

хочу поставить его в свой таз

Брызговики от бмв ставь

Ну там домбок типа

Ломбок

и тонировка по кругу

spring-jdbc зависит от спринговых транзакций и датасоуса

Парни, я прибыл из будущего - там все пишут на микросервисных монадах. Срач про спринг бессмысленный. Скоро все поймете

Парни, я прибыл из будущего - там все пишут на микросервисных монадах. Срач про спринг бессмысленный. Скоро все поймете

Фаас?

На кложуре

Все и так пишут на микросервисах