Pull to refresh
39
0
Борис Ванин @fogone

Пользователь

Send message
чесслово, не понимаю я. Вы же не пишете другие классы с расчетом на то, что их пользователи будут необходимые для работы зависимости писать напрямую в поля рефлекшеном да ещё и после создания объекта, чем же те классы которые попадут в контейнер хуже? Более того, в контекст часто попадают объекты библиотечных классов, которые знать ничего не знают о контейнере и у них обычный конструктор, который вы и будете использовать.
Как вы думаете, реализуется бин со скоупом? Почему вы думаете, что между инжектом в методы и в конструктор в данном случае есть какая-то разница? Вы же не думаете, что разные интсансы сетятся в поле каждый раз, когда окружающий скоуп меняется? Вот тут можно посмотреть подробнее.
Я вообще имел ввиду не столько кривые руки, сколько аспект влияния интегрируемых спрингом решений на скорость запуска. Ну и нюансы использования технологий спринга — например, если есть 100000 классов, которые нужно прошерстить на предмет аннотаций, то это займет некоторое время даже не смотря на то, что спринг это делает не рефлексией, специальной тулзой для анализа байт-кода. Но это не значит, что спринг плохой, просто не надо так делать. И вообще лучше стараться избегать скана не только из за скорости.
Что например? Может показаться, что мелочи, но на мой взгляд совсем нет, да и не так иллюзорно это, когда спринг из коробки поднимает стек нетфликса, например.
Да, прошу прощения, я не туда ответил. Мне тоже интересно, что это за приложение такое и почему оно 30 секунд стартует. Уверен, что спринг тут играет очень косвенную роль. Например включено сканирование всех 100500 классов проекта и зависимостей. Или кучу времени инциализируется хибернейт и тд…
У меня быстро запускается, может вы что-то перепутали? Можете ссылочку дать на приложение, которое долго запускается из за спринга?
Так и всё же, что же там за страшная рефлексия такая, не эта случаем?
Во-первых, Spring — вещь общая, и вполне возможно, что собственное решение будет проще и лучше (в том числе — на long term).

А так же вполне возможно, что не будет. Только во втором случае на это придется потратить время, силы и деньги. И что точно получится ты пока не знаешь, а спринг уже вполне понятный. По большей части, конечно.
Во-вторых, что если многие из этих «решений» на самом деле решают проблемы, которые породил сам Spring.

Уже не первый раз про это слышу, что собственно вы имеете ввиду? Приведите топ 10 проблем, которые создал спринг, которые он сам же и решает. Т.е. поймите правильно, спринг безусловно решает свои внутренние проблемы, с этим спорить глупо. И да для этого написано много кода. Но эти проблемы второстепенны по сравнению с теми какое количество решений моих проблем у него есть.
Можете привести пример, когда что-то с чем-то не спринговое нужно интегрировать, это действительно проблема и Spring ее решает?

Ну как, запустить сервер, сконфигурировать его, пробросить в него мэппинги контроллера, где-то хранить инстансы сервисов, каким-то образом драйвить транзакции, скорнфигурировать какой-нибудь хибернейт, создать для него инфраструктуру, сконфигурировать датасорс и тд. Спринг бут делает это десятком строк, если же вы будете делать это всё руками у вас выйдет не одна сотня. Потому что все работающие в этом приложении решения интегрированы за вас. Да, спринг нужно уметь готовить, но если умеешь, то он дает свои профиты.
Пишите из 2003 года?
готовые решения — это не однозначное добро

я никогда не говорил, что готовые решения это однозначное добро. Только конкретно о спринге и с большими оговорками на то, что не стоит воспринимать спринг как универсальное решение для всех и вся и рассчитывать, что там нет проблем или решены любые ваше потребности. Это готовое решение по интеграции, которое часто при прочих равных на мой взгляд выигрывает перед самописным решением, когда речь идет о проекте, которые будет развиваться и разрабатываться не одним человеком. Во многом из за большого числа уже готовых интеграций, которые не без греха, чего уж, но работают без необходимости всё это писать самому.
особенно когда к этому готовому решению городить столько костылей, что объем костыльного кода начинает превышать объем самого «решения»

Да, спринг часто кастомизируют, тем он и ценен, но вот так, чтобы объем кода кастомизации превышал объем бизнес-кода… такого я еще не видал. Да еще и весь костыльный, точно ли тут дело в спринге?
Простите, но в ваших комментах сквозит нечто вроде детского страха перед тем, что сделали «взрослые дядьки»: мол, они могут сделать хорошо, потому что взрослые,

Я давно не меряюсь размером со «взрослыми дядьками», с опытом просто приходит понимание, что если ты хочешь сделать продукт, то нужно принимать решения, которые будут позитивны для продукта и его развития в существующих условиях, а не для тебя конкретно. Да, спринг мне нравится, но так же мне нравится например котлин, но я не тащу его в каждый большой проект, потому что кроме меня на этом проекте есть и другие люди и некоторые ожидания бизнеса, так что пишу на котлине в свободное от работы время. Хотя котлин сам по себе намного эффективнее джавы, но знакомость для разработчиков бывает важнее, если в проекте участвует больше трех человек и проект развивается.
Ну так не уверен — не берись, уверен — делай и никого не слушай. «Главное понимать что ты хочешь и что можешь.»

Управление сложностью большой программной системы дело не простое, а прогнозировать такое управление на будущее и подавно. Поэтому уверенным в таком вопросе быть никак нельзя, тут приходится решать вопросы по мере их поступления. В какой-то мере и в этом спринг лучше самописного решения, потому что он долгие годы собирает типовые решения типовых проблем, которые можно если не использовать из коробки, то по крайней мере в разумное время приспособить под свои нужды.
А если «велосипед» грамотно написан, там не в чем разбираться, т.к. всё делается очевидно

Когда проект растет, то велосипеды превращаются в пятиколесных монстров на ручной тяге куда монструознее спринга. Во многом из за того, что тебе нужно писать мякотку и выдавать бизнес-фичи, а все эти обвязки и интеграции часто остаются на сдачу или когда уже совсем припрет.
Вы будете разбираться с местным использованием чужой магии, вот и всё.

Поделитесь какого рода магию вы постигли пол года изучая спринг? При том, что до этого вы его уже использовали. Т.е. я не исключаю того, что можно так напедалить на спринге, что и за пол года не разберешься, но в спринге ли тут дело? Если стараться пользоваться стандартными средствами, по большей части хватает спринговой документации, чтобы разобраться с тем, что ты написал.

Гляньте, например, guice как пример DI. За 1 минуту подключаете и используете во всю.

Вы так говорите, как будто спринговый di подключается дольше.
А бывает DI вообще без контейнеров, который еще и валидируется компилятором.

Я так и написал.
У меня ушло примерно полгода

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

Ругайте на здоровье. Я нисколько не против. Просто вы написали, что на спринге только хеловорлды хорошо идут, что я честно говоря могу объяснить только тем, что вы просто не умеете его готовить. Что в целом тоже не зазорно, потому что я бы не назвал его простым и как тут выше замечали он требует поиска своего пути, в том плане, что на нем можно решать проблемы очень по-разному, что приводит к разной архитектуре и разному пониманию происходящего. Так что я нисколько не против того, что кому-то из за этого или по другом причинам этот фреймворк не нравится. Как я уже писал выше, выбирайте фреймворк по себе и по потребностям, кому как удобнее это по большому счету вкусовщина.
Это не холивар, а указание на неточности вашего комментария, я (честно говоря) и не ждал на него ответа.
Очень люблю писать велосипеды, но с опытом приходит понимание, что обычно лучше использовать готовое решение, особенно если оно знакомо другим разработчикам и решает все твои задачи. А велосипеды требуют не меньшей работы, чем разобраться со спрингом хотя бы из за того, что для всех его частей придется писать тесты, а потом еще ловить баги, проблемы секьюрити, корнер-кейзы и тд. Да еще если кто-то после тебя на твои велосипеды придет, то будет материть тебя на чем свет стоит (а то и решит, что её нужно переписать), потому что спринг знаком более-менее каждому современному джава-разработчику, и имеет очень неплохой уровень качества — как кода и архитектуры, так и проработанности деталей и покрытия тестами, а ваш велик придется исследовать с нуля, неизвестно какого он качества, да и не был бы я уверен, что по ходу развития системы сложность вашей собственной интеграции не станет существенно выше её же в спринге.
Если вы имеете ввиду веб-приложение с реактором, то можно посмотреть на примеры из бута.
перфекционист в чате!1
Почему, когда я подключаю такой огромный и мощний фрейморк, спринг, я не могу просто написать

У спирнга нет никаких проблем с отдачей файла, zirix написал выше как сделать это одной строкой, если надо. Ваше негодование по поводу того, что спринг-вебмвц гибкий и позволяет сложно кастомизировать ответ прямо из котроллера звучит просто смешно, видимо вам просто никогда не приходилось этим пользоваться.
У спринга есть все возможности для этого, и эту элементарную вещь они могли добавить лет так 7-8 назад.

Примерно 7-8 лет назад это и там и появилось.
Я не хочу писать кучу конфигов, утилитарных методов, адаптеров и прочей чепухи, используя такой огромный фреймворк.

Кто же вас заставляет? Даже если вас насильно засадили писать приложение на спринг-вебмвц, то для простых случаев не нужно писать кучу конфигов, утилитарных методов и прочей чепухи, а вот если нужно что-то кастомизировать, то другой фреймворк может просто в лужу сесть, а в спринге обычно всегда есть способ кастомизировать поведение, как раз во многом из за хорошей модульности и продуманности этого фреймворка и webmvc в том числе.
а я своём веб-аппе тяну спринг фреймворк весом в 50 мегабайт

в теории это возможно если тянуть как минимум 5 разных версий всех зависимостей, но что-то мне подсказывает, что это не будет работать. Я это к тому, что ваша оценка размера спринга более чем преувеличена. Да и не так уже это страшно для нынешних реалий 10 мегабайт, если они удовлетворяют большинству потребностей.
который из коробки не понимает что если контроллер возвращает файл — то надо вернуть файл!

Вы уже трижды продекламировали эту мысль при том, что спринг отлично с этой задачей справляется. У спринга своя абстракция ресурсов и именно её он и поддерживает в качестве возвращаемого значения, что на порядок гибче, чем просто файл. Тем более, что файл это один из видов доступных ресурсов.
Ну да, а так как я очень ленив, я люблю, когда за меня эту работу делает готовый фреймворк. Я как программист всегда думаю о том как автоматизировать любую деятельность, почему же интеграцию обязательно нужно делать руками?
Спринг это система интеграции. Если вам нужен перфоманс в ответах, не нужно использовать хибернейт для обращения к базе, а возьмите какое-нибудь другое решение, которое будет для этого предназначено, а не винить поезд за то, что он не летает, это же просто глупо. Более того можно без проблем прикруть акку к спрингу. Еще раз: спринг это система интеграции. Его сила в возможности быстро и удобно интегрировать какие-то решения или использовать готовые интеграции из коробки. Если интегрировать нечего, а надо отвечать быстро на простые запросы, то вероятно, что спринг просто не нужен. И да, было бы интересно взглянуть на тесты и их результаты, на которые вы ссылаетесь в своем комментарии.

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity