Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 92
А не увеличится ли страшным образом время поднятие приложения из за того, что надо будет сканировать все пакеты на предмет поиска там спринг бинов? Как вообще это происходит? Спринг читает класспас, раскрывает все jars, загружает все классы и ищет классы с аннотациями?
Или как то по другому?
Или как то по другому?
Увеличится или нет — это вопрос отдельный, проблема в другом.
Хорошей практикой считается разнесение контекстов — application context и servlet context (n-штук) и, соответственно, бинов в них по scope'у их работы (loose coupling, tight cohesion в действии). Куда в таком случае совать директуиву сканирования всех пакетов? Во все — будем иметь по инстансу на контекст, в один application context — не круто, там будут ненужные контроллеры и т.п.
В общем спорный момент.
Хорошей практикой считается разнесение контекстов — application context и servlet context (n-штук) и, соответственно, бинов в них по scope'у их работы (loose coupling, tight cohesion в действии). Куда в таком случае совать директуиву сканирования всех пакетов? Во все — будем иметь по инстансу на контекст, в один application context — не круто, там будут ненужные контроллеры и т.п.
В общем спорный момент.
Пипец… Был XML, превратился в Java-код. ЗАЧЕМ ВСЁ ЭТО? Начинайте уже писать на нормальных языках и фреймворках!
Java не является динамическим языком. Там можно только через аннотации, IoC и XML что-то сделать. Но вообще XML пишется ровно один раз дальше пишется код.
>Там можно только через аннотации
Это мягко говоря не совсем правда. www.picocontainer.org/introduction.html. И это далеко не единственный.
Это мягко говоря не совсем правда. www.picocontainer.org/introduction.html. И это далеко не единственный.
Это концептуально тожесамое что и Spring, только без xml. Те же яйца только сбоку. Еще не факт что удобнее.
Затем, что за этот ненормальный язык и ненормальный фреймфорк платят. И очень неплохо. Чего и вам желаю.
Платят за качественно сделанную работу, за язык платят только имбецилы. Работать на имбецилов мне совесть не позволяет. У Java есть куча применений (я сам на яве пишу часто), но веб в данное множество не входит. На сях тоже иногда пишут сайты, но зачем — одному Богу известно.
Иногда у имбецилов СТОЛЬКО денег…
Не думаю, что вы правы. Бывает, что у крупной компании имеется большое Java legacy в каких-то бекендах и тогда одним из условий для упрощения интеграции нового веба и легаси может быть использование Java для веба. Данное условие вытекает не из имбецильности, а из исходных данных в поставленной задаче. Не ну конечно всегда можно написать какие-то обёртки в виде сервисов или ещё чего, но это дополнительные трудо-затраты и такой путь может быть невыгодным. И да, в таких случаях ребятами приходится делиться своими СТОЛЬКИМИ деньгами. Тем не менее, нам опять же платят НЕ ЗА ЯЗЫК, нам платят за качественное решение поставленной задачи. На язык как таковой насрать всем, это просто инструмент. Как молоток или лом. Не более. Да, иногда и ломом приходится гвозди забивать, потому что молоток коллега сломал по пьяне. Но это не значит, что лом создан для забивания гвоздей и вам работодатель платит за использование лома вместо молотка.
Стало жутко интересно, а чем это Java не подходит для веба? Хочется конкретики.
И еще один вопрос, а что же на ваш взгляд лучше всего подходит для веба и почему?
И еще один вопрос, а что же на ваш взгляд лучше всего подходит для веба и почему?
И сразу хочется открыть вам глаза что у на java написаны не только старые проекты, как вы высказались: «Java legacy», на нем пишется просто тьма тьмущая новых и интересных проектов.
Ну если ваша работа как веб-программиста заключается исключительно в рефакторинге… На практике же оказывается, что клиенту надо по двадцать раз на дню в шаблоне пиксели двигать туда-сюда, да урлы переименовывать для более красивого чпу. Я уже написал выше — у явы есть ниши, но веб в это множество не входит.
веб бывает очень разный, и в нем у Java есть ниши. А пиксели двигать — это работа верстальщика, который вполне с Java-программистами уживается (если аккуратно подходить к выбору и освоению фреймворков)
Статья бредовая. Во-первых, на PHP свет клином не сошёлся. Во-вторых, автор статьи совсем не понимает нишу в вебе у PHP. Для уютного бложика не нужен крон и персистенс обьектов в памяти между запросами, а строить на PHP какую-нибудь веб-ориентированную CRM я бы не стал.
> Это неотъемлемый процесс развития системы.
Это немного не про веб. В большинстве веб-проектов полноценный рефакторинг никогда не пригодится, а вот пиксели двигать очень даже надо. Как правило, в вебе старый код всех всем устраивает, а новый функционал, по-хорошему, встраивается модульно: добавили новый контроллер и появился форум; добавили ещё один — и у нас форма обратной связи. А вот поля для формы в базе и на экране будут меняться тыщу раз на дню. Компилять яву задолбаетесь.
Это немного не про веб. В большинстве веб-проектов полноценный рефакторинг никогда не пригодится, а вот пиксели двигать очень даже надо. Как правило, в вебе старый код всех всем устраивает, а новый функционал, по-хорошему, встраивается модульно: добавили новый контроллер и появился форум; добавили ещё один — и у нас форма обратной связи. А вот поля для формы в базе и на экране будут меняться тыщу раз на дню. Компилять яву задолбаетесь.
Вы это, html и css код генерите в сервлетах, что ли, что перекомпилить каждый раз приходится, когда клиент решил подвинуть что-то на пискель?
Ну, тогда действительно, с таким подходом ну его, эту веб-разработку на java.
А мы, к примеру, ничего не перекомпиливаем.
Ну, тогда действительно, с таким подходом ну его, эту веб-разработку на java.
А мы, к примеру, ничего не перекомпиливаем.
Может мы с вами совсем разные веб-проекты создаем? Что вы понимаете под словом веб-проект? Сайт? Веб — это не только сайты.
Как меня задолбали так называемые вебмастера.
Я работаю с JEE 4 года, я не знаю такого слова, мать его, «шаблон», в том понимании чтобы это было связано с пикселями. Есть САЙТЫ, а есть ВЕБ-ПРИЛОЖЕНИЯ, понимаете.
Извините за резкость.
Я работаю с JEE 4 года, я не знаю такого слова, мать его, «шаблон», в том понимании чтобы это было связано с пикселями. Есть САЙТЫ, а есть ВЕБ-ПРИЛОЖЕНИЯ, понимаете.
Извините за резкость.
Вы правы для двигания пикселов в шаблонах Java плохо подходит, но двигание пикселов в шаблонах это далеко не весь веб. Если вам будет нужен интеграция Enterpise-решениями, SOA то альтернатива в общем то одна .NET с завязкой на Windows.
Интеграции делаются через адаптеры и что будет показывать «веб» — по барабану. Исключение — хитрый легаси, но это сегодня редкость. Так что ява и тут не катит.
И разводить зоопарк из разных технологий нет уж увольте.
Да, только жависты такие упоротые… Ещё раз повторяю главную идею — инструмент выберается в соответствии с задачей, а не с вашими личными пожеланиями. У вас и так зоопарк как бы вы ни любили свою яву: куча упоротых фреймворков, анты с мавенами, десяток несовместимых апп-контейнеров и т.д. Не надо тут про зоопарки, оок?
Я не пишу на Java вообще. Язык знаю постолько постолько иногда приходится сталкиватся. Поработав в индустрии некоторое время вижу что время PHP безвозвратно ушло по крайней мере тренд для меня виден. Для более дешовых решений есть более производительные и безопасные Python/Ruby для более сложных и дорогих Java/.NET.
А поддержка качественных решений на PHP стоит слишком дорого изза плохого дизайна языка, зоопарка в библиотеках и катастрофически малого количества действительно хороших разработчиков, потому что джуниоров много, а к профи обычно переквалифицируются на что-то получше и поудобнее.
Конечно PHP ещё лет 5-10 наверное будет гнить как Delphi в своё время.
А вы продолжайте держаться за PHP года за 3 будете чесать репу как знакомые Delphi-сты.
А поддержка качественных решений на PHP стоит слишком дорого изза плохого дизайна языка, зоопарка в библиотеках и катастрофически малого количества действительно хороших разработчиков, потому что джуниоров много, а к профи обычно переквалифицируются на что-то получше и поудобнее.
Конечно PHP ещё лет 5-10 наверное будет гнить как Delphi в своё время.
А вы продолжайте держаться за PHP года за 3 будете чесать репу как знакомые Delphi-сты.
Причём здесь, блядь, PHP? Почему большинство джавистов на столько тупы, что в разговорах про веб ни с чем яву кроме PHP сравнить не могут? Мне насрать на PHP, я говорю что ява, блять, НЕ КАТИТ В ВЕБЕ! В вебе есть питон с рубями и груви, кому мигряться сложно. Причём PHP? Обьясните мне! Откуда вы его высрали? Если у вас PHP головного мозга — не пишите тут.
Да потому что вы сами упомянули PHP в соседнем треде как пример, это во первых.
Во вторых ещё раз повторю я НЕ ПИШУ НА Java, ВООБЩЕ НИЧЕГО, но что она может и о границах применения технологиии знать обязан.
Кстати интересно вы привели пример с Groovy, который базируется на JVM, что только доказывает что Java — это не только ценный мех JSP, serlets, beans, но и надёжная и маштабируемая платформа для альтернативных решений вроде Groovy, Clojure, Scala etc.
Во вторых ещё раз повторю я НЕ ПИШУ НА Java, ВООБЩЕ НИЧЕГО, но что она может и о границах применения технологиии знать обязан.
Кстати интересно вы привели пример с Groovy, который базируется на JVM, что только доказывает что Java — это не только ценный мех JSP, serlets, beans, но и надёжная и маштабируемая платформа для альтернативных решений вроде Groovy, Clojure, Scala etc.
«я говорю что ява, блять, НЕ КАТИТ В ВЕБЕ»
В мемориз, однозначно :)
В мемориз, однозначно :)
Перечислите мне сайты из Top100 алексы, написанные на руби, пожалуйста? :)
Не только среди джавистов встречаются упоротые. Вот вы же не джавист? :)
Забавно что вы критикуете яву по видимому слаба разбираясь в ней.
Забавно что вы критикуете яву по видимому слаба разбираясь в ней.
Ну, IDE вроде JetBrains IDEA обычно нормально работают с переименованиями бинов и прочего из спринговских конфигов. То есть если я в Java-коде переименую класс, то IDEA подправит XML-файлы.
а что по вашему нормальные языки? может ся, хорошего програмера под которую найти даже задорого нереально? или чих-пых, который из-за отсутствия банальщины приходится обвешивать костылями вроде memcached и кучей инклюдов? жаба еще всех переживёт и меня с вами в том числе. жаба это уже как IBM — всегда была и всегда будет.
Я уже написал выше — у явы есть ниши, но веб в это множество не входит. Если вам для решения любой чих-пых проблемы требуется memcached, то это вина прямизны ваших рук. К тому же PHP никогда не стремился стать универсальным решением. У него, так же как и у Java, есть своя ниша и в ней он переживёт любую яву. Если вы не умеете выбирать инструмент для выполнения работы — это ваш недостаток, а не инструмента.
да с каких пор наличие чего-то в языке стало его недостатком? у жабы есть та же ниша что и у php — мелкие вебовские говнопроекты. бери jsp и пиши наздоровье. но даже в этой нише, даже если не использовать ни один сервлет, и то жаба пхп немного уделывает.
в 90е для веба был популярен некий perl. появился php — про perl забыли. и теперь всякие ленты.ру с ужасом ищут продолжателей дела бородатых програмеров. плюс же жабы — человек, который вчера писал на swing, после двухдневной инъекции общей теории «как работает world wide web и http», уже начинает что-то сам пописывать.
а после недельной уже впринципе ничем особо не отличается от матерого веб-программера. а через месяц уже связывает бины через spring или ejb не хуже чем его более бородатые коллеги.
я лично php и прочие скриптоязыки за программирование вообще не считаю. это так — на уровне bash только для web. у нас в конторе например, знание php обязательно, как и знание что такое cp и rm -rf. потому что на php впринципе невозможно писать серьезные вещи командно.
простой пример — сколько теперь facebook тратит на оптимизацию кода, сколько они ставят машин, уже дошли до того что транслятор php->c сами писать начали (и с их миллиардами — прикинь — до сих пор не закончили). вместе с тем есть такой себе linkedin, у которого трафика всего в 4 раза меньше (для их объёмов — 75% не показатель, условия масштабируемости примерно одинаковы), живёт и вы даже не знаете на чём он написан, как устроен и почему не падает. а ведь если не считать тупо уников в сутки, функционала в linkedin в десятки раз больше.
я со своей стороны прекрасно знаю кухню высоконагруженных приложений под веб (5+ лет руководства веб-ориентированной девелоперской конторой) и могу сказать что кроме жабы и питона нынче нигде ловить нечего. разве что в ruby, его у меня нет времени посмотреть.
в 90е для веба был популярен некий perl. появился php — про perl забыли. и теперь всякие ленты.ру с ужасом ищут продолжателей дела бородатых програмеров. плюс же жабы — человек, который вчера писал на swing, после двухдневной инъекции общей теории «как работает world wide web и http», уже начинает что-то сам пописывать.
а после недельной уже впринципе ничем особо не отличается от матерого веб-программера. а через месяц уже связывает бины через spring или ejb не хуже чем его более бородатые коллеги.
я лично php и прочие скриптоязыки за программирование вообще не считаю. это так — на уровне bash только для web. у нас в конторе например, знание php обязательно, как и знание что такое cp и rm -rf. потому что на php впринципе невозможно писать серьезные вещи командно.
простой пример — сколько теперь facebook тратит на оптимизацию кода, сколько они ставят машин, уже дошли до того что транслятор php->c сами писать начали (и с их миллиардами — прикинь — до сих пор не закончили). вместе с тем есть такой себе linkedin, у которого трафика всего в 4 раза меньше (для их объёмов — 75% не показатель, условия масштабируемости примерно одинаковы), живёт и вы даже не знаете на чём он написан, как устроен и почему не падает. а ведь если не считать тупо уников в сутки, функционала в linkedin в десятки раз больше.
я со своей стороны прекрасно знаю кухню высоконагруженных приложений под веб (5+ лет руководства веб-ориентированной девелоперской конторой) и могу сказать что кроме жабы и питона нынче нигде ловить нечего. разве что в ruby, его у меня нет времени посмотреть.
Добавлю еще к последнему абзацу Scala и Lift framework для нее.
А как же .net и asp mvc?
Причём тут PHP? Я на PHP не пишу. Есть классный питон, есть обалденный руби, в конце концов, если вам нужна JVM и мягкая миграция специалистов, то есть груви и скала. Но яве как языку в вебе делать НЕЧЕГО! Вообще! Ни в высоконагруженном, ни в бложечном для хомячков.
Толсто, очень толсто.
Я прочитал все ваши ответы в этой ветке.
Вы _действительно_ считаете Java неподходящим языком для веба? Или это обычный троллинг ..?
Вы _действительно_ считаете Java неподходящим языком для веба? Или это обычный троллинг ..?
За вариант спасибо, но ресурсоёмкость будет ужасная…
Думаю, что «избавление от XML» — достаточно сомнительный лозунг, тем более когда это становится бездумной самоцелью.
Существует такое понятие как «coupling». Применение современных аннотаций сильно увеличивает сцепление — почти все классы становятся намертво связаны со спрингом, классы контроллеров начинают хранить привязку к URL внутри себя, в классах сущностей хранятся имена таблиц и колонок и прочее-прочее. В общем — вроде бы хотели все упростить, а потом получается, что в сложном проекте все становится только хуже.
Кроме того автовайринг — это достаточно сомнительная вещь в сложных проектах. Когда бинов с реализацией одного и того же интерфейса становится несколько приходится уточнять их имена прямо в аннотациях, а это опять усиливает сцепление между классами.
В общем, я не одобряю.
Существует такое понятие как «coupling». Применение современных аннотаций сильно увеличивает сцепление — почти все классы становятся намертво связаны со спрингом, классы контроллеров начинают хранить привязку к URL внутри себя, в классах сущностей хранятся имена таблиц и колонок и прочее-прочее. В общем — вроде бы хотели все упростить, а потом получается, что в сложном проекте все становится только хуже.
Кроме того автовайринг — это достаточно сомнительная вещь в сложных проектах. Когда бинов с реализацией одного и того же интерфейса становится несколько приходится уточнять их имена прямо в аннотациях, а это опять усиливает сцепление между классами.
В общем, я не одобряю.
Позвольте возразить.
По поводу
Я не думаю что в проекте так уж часто будет меняться фреймворк, я думаю, что этого вообще не может произойти особенно на поздних стадиях, а если уж и произойдет, то не думаю что xml вместо аннотаций вас спасет.
Дальше
Объясните, плиз, почему это плохо? Например я как раз сейчас дочитываю Java Persistance with Hibernate, так там примеры всех мапингов даны в xml и аннотациях, так вот аннотированный код не в пример читабельнее, да и банально его меньше плюс не нужно лезть в другой файл(перед этим его нужно найти, что не всегда бывает просто ибо не все следуют конвенциям ;)), всё сразу как на ладони. По моему плюсы очевидны.
Это тоже непонятно, что вам даст то, что урлы будут в xml? Хотя тут я частично с вами согласен, но все же считаю что оба варианта уместны и это дело вкуса.
По поводу
все классы становятся намертво связаны со спрингом
Я не думаю что в проекте так уж часто будет меняться фреймворк, я думаю, что этого вообще не может произойти особенно на поздних стадиях, а если уж и произойдет, то не думаю что xml вместо аннотаций вас спасет.
Дальше
в классах сущностей хранятся имена таблиц и колонок и прочее-прочее
Объясните, плиз, почему это плохо? Например я как раз сейчас дочитываю Java Persistance with Hibernate, так там примеры всех мапингов даны в xml и аннотациях, так вот аннотированный код не в пример читабельнее, да и банально его меньше плюс не нужно лезть в другой файл(перед этим его нужно найти, что не всегда бывает просто ибо не все следуют конвенциям ;)), всё сразу как на ладони. По моему плюсы очевидны.
классы контроллеров начинают хранить привязку к URL внутри себя
Это тоже непонятно, что вам даст то, что урлы будут в xml? Хотя тут я частично с вами согласен, но все же считаю что оба варианта уместны и это дело вкуса.
Я соглашусь, что полностью избавиться от зависимостей к Spring'у вряд ли возможно и даже вряд ли нужно. С другой стороны лично для меня принцип уменьшения сцепления является аксиоматичным и не раз оправдывавшим себя. Поэтому при прочих равных я выберу вариянт с меньшим сцеплением. Но без экстремизма, конечно.
К счастью, что в настоящее время есть хорошая тенденция к стандартизации: например вместо интерфейсов InitializingBean/DisposableBean можно применять @PostConstruct/@PostDestroy (штатные из JDK!), вместо аннотаций Hibernate использовать штатные аннотации JPA2, опять же аннотации для валидации также стандартизированы — это очень хорошо.
Чем плохо сцепляться с Hibernate? Для подавляющего числа проектов — наверное ничего плохого нет. Я лишь вижу ограничение в свободе. Если вы будете выставлять эти сущности наружу, клиенту придется тащить еще и один пакет из Hibernate, который ему вообще-то не нужен. Можно, конечно, сделать DTO — но это уже дополнительные теложвижения. Также если ваше коммерческое приложение поддерживает несколько СУБД, бывает полезным иметь несколько конфигурационных файлов для каждой — со своими особенностями, которые обязательно возникнут.
Но, собственно, наибольшее сомнение у меня вызывает автовайринг. Как программист использующий кучу custom-контекстов для тестов, а также пишущий в стиле composition-over-inheritance с большим количеством одноинтерфейсных прокси для себя вижу в автовайринге большую головную боль — тем более, что вы можете быть увереным, что у вас все правильно связалось только в рантайм, запустим приложение или тест с контекстом.
К счастью, что в настоящее время есть хорошая тенденция к стандартизации: например вместо интерфейсов InitializingBean/DisposableBean можно применять @PostConstruct/@PostDestroy (штатные из JDK!), вместо аннотаций Hibernate использовать штатные аннотации JPA2, опять же аннотации для валидации также стандартизированы — это очень хорошо.
Чем плохо сцепляться с Hibernate? Для подавляющего числа проектов — наверное ничего плохого нет. Я лишь вижу ограничение в свободе. Если вы будете выставлять эти сущности наружу, клиенту придется тащить еще и один пакет из Hibernate, который ему вообще-то не нужен. Можно, конечно, сделать DTO — но это уже дополнительные теложвижения. Также если ваше коммерческое приложение поддерживает несколько СУБД, бывает полезным иметь несколько конфигурационных файлов для каждой — со своими особенностями, которые обязательно возникнут.
Но, собственно, наибольшее сомнение у меня вызывает автовайринг. Как программист использующий кучу custom-контекстов для тестов, а также пишущий в стиле composition-over-inheritance с большим количеством одноинтерфейсных прокси для себя вижу в автовайринге большую головную боль — тем более, что вы можете быть увереным, что у вас все правильно связалось только в рантайм, запустим приложение или тест с контекстом.
Конечно да. Но зачем вот как раз таки dataSource класть в java класс? Чтобы потом пересобирать приложение при смене источника данных? NoWay!
xml нужен только для общих описаний, для бинов он жесть, говорю как работавший с ejb2.1.
есть такой сервер — glassfish v3, ejb3.1, eclipselink, servlets 3.0, jsf 2 и тд…
разработка сложного приложения занимает дни!
есть такой сервер — glassfish v3, ejb3.1, eclipselink, servlets 3.0, jsf 2 и тд…
разработка сложного приложения занимает дни!
Нет, что Вы! Надо использовать решения от Oracle/IBM/подставьте своё. Тогда разработка занимает месяцы/годы, требует десятков человеческих ресусров. А уж какие бюджеты, ах какие бюджеты…
к этому стоит еще добавить CDI (AKA Weld), это посерьезнее аннотаций Spring
Стоит ли избавляться от XML целиком? На мой взгляд, XML предпочтительнее при регистрации бинов (потому что все в одном месте, очень удобно), но вот когда в XML требуется описывать структуры сущностей (hibernate) — я пас, это слишком муторно.
Лично я считаю, что как подход можно иметь в виду. Статью переводил имея в голове чью-то фразу с хабрахабра в стиле «зачем столько хмл? можно же аннотациями!». Разумеется, что идея-фикс избавления от XML не катит в нормальных условиях, но некоторые моменты можно использовать в разработке.
Конечно, про аннотации спринга нужно знать обязательно, просто хочу сказать, что не стоит на них зацикливаться.
Еще хотел добавить. Некоторым людям, которые либо не знакомы с java, либо знакомы достаточно поверхностно может и правда показаться, что разработка с использованием контекстов в xml — это нуднейший ад и жестокий трэш.
Тем временем все современные IDE (я конечно порекомендую IntelliJ IDEA) автоматически и в реальном времени распарсят все ваши контексты, расцветят их, подскажут что и в каком месте подставить, покажут какие ссылки и/или значения подставлены неправильно, где ошибка схемы XML, где несоотвествие типов, рядышком с классом выведут иконку ведущую на его описание в контексте и прочая, прочая, прочая. Это облегчает работу на порядок — понимание этого приходит только тогда, когда все эти радости становятся недоступны.
Еще хотел добавить. Некоторым людям, которые либо не знакомы с java, либо знакомы достаточно поверхностно может и правда показаться, что разработка с использованием контекстов в xml — это нуднейший ад и жестокий трэш.
Тем временем все современные IDE (я конечно порекомендую IntelliJ IDEA) автоматически и в реальном времени распарсят все ваши контексты, расцветят их, подскажут что и в каком месте подставить, покажут какие ссылки и/или значения подставлены неправильно, где ошибка схемы XML, где несоотвествие типов, рядышком с классом выведут иконку ведущую на его описание в контексте и прочая, прочая, прочая. Это облегчает работу на порядок — понимание этого приходит только тогда, когда все эти радости становятся недоступны.
Да, и тут ранее делали замечение про рефакторинг. Вы удивитесь, но рефакторинг работает замечательно и для xml-контекстов.
можно без веб фрагментов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Spring Framework без XML… совсем!