Comments 30
Вот только сервлеты — это часть J2EE.
Формально вы конечно правы!
Но на практике это скорее простой и удобный стандарт Java веб-приложений. Например Томкат нельзя считать полноценным JEE-сервером — всё что в нем есть — это как раз-таки одни сервлеты :)
Но на практике это скорее простой и удобный стандарт Java веб-приложений. Например Томкат нельзя считать полноценным JEE-сервером — всё что в нем есть — это как раз-таки одни сервлеты :)
[зануда-mode]
Tomcat — web-контейнер. Web-контейнер — часть JavaEE.
[/зануда-mode]
Tomcat — web-контейнер. Web-контейнер — часть JavaEE.
[/зануда-mode]
Кстати, предлагаю переписать пример, например, под Netty, чтобы даже формально не докапывались ;)
Пишите дальше, только было бы интереснее читать о всяких тонких и хитромудрых моментах реализации, потому что остальное должен был читать каждый новичок.
Небольшой вопрос, о котором часто забывают: «Зачем?» Можно и HTTP запрос в ручную разбирать, но зачем?
Больше производительность, меньше потребление памяти, большая управляемость/гибкость. На мой взгляд, еще и более удобно. Проще писать и поддерживать. Здесь даже велосипеды писать не нужно — есть готовые библиотеки, выполняющие только то, что нужно. Мы так даже сервлеты не используем. Просто Grizzly напрямую.
Ну если сравнивать со Spring то производительность выше только при старте приложения, ибо тратится время на чтение конфика, создание бинов и прописывание зависимостей. Да и на счет удобства я бы не согласился — декларативный конфиг поправить, часто проще, чем переписать код.
Кто мешает использовать конфиги в любом удобном виде с тем же Grizzly? Я же не просто так говорю об удобстве. Мой выбор — так вообще HOCON или Kotlin DSL, там, где без него можно обойтись (почти везде).
Не соглашусь, что декларативный конфиг проще править. Для кода существуют практики рефакторинга, а вот XML читается и правится намного сложнее.
Если, конечно, предположить, что рабочее место находится в бункере без доступа к интернету и на компьютере кроме блокнота ничего нет, то да — сложнее. А если все же использовать современную IDE, умеющую рефакторить кроме кода еще xml и конфиги (Intellij Idea, например), то проблем совершенно никаких нет.
P.S. Если уж мы предположили бункер, то вполне вероятно что и доступа к JDK у нас тоже нет, таким образом получается что единственный способ хоть как то изменить поведение программы — это правка xml, т.к. не требует перекомпиляции.
P.S. Если уж мы предположили бункер, то вполне вероятно что и доступа к JDK у нас тоже нет, таким образом получается что единственный способ хоть как то изменить поведение программы — это правка xml, т.к. не требует перекомпиляции.
Ответ на вопрос «зачем» дан в самом начале статьи — посмотрите внимательнее :)
Плюс всегда приятно опуститься на уровень «пониже», чтобы самому познать то, что скрыто от вас в Больших Фреймворках.
Плюс всегда приятно опуститься на уровень «пониже», чтобы самому познать то, что скрыто от вас в Больших Фреймворках.
Забавно, я считал что, обычно все бывает с точностью до наоборот: после реализации IoC руками переходят к библиотекам, позволяющим сделать тоже самое, но значительно проще)
Советую также глянуть в сторону легкого spark и ninja-framework.
Для очень малюсеньких проектиков можно обойтись и без фреймворков. Но как только речь зайдëт о скалирование, кэширование, security и т.д. — то без фреймворках придëться накручивать велосипеды и наступать на грабли, о которые фреймворки спотыкались десять версий назад.
Но в рамках учебной практики, конечно, очень полезно попрограммить вне фреймворках.
Но в рамках учебной практики, конечно, очень полезно попрограммить вне фреймворках.
Очень распространенный миф. Фреймворки призваны решать как раз простые типовые задачи. Они предлагают унифицированное архитектурное решение, определенный набор функционала, а также определенные методы разработки и тестирования, которые бывают полезны в команде не очень сильных девелоперов. И это основная почему люди привыкли использовать фреймворки — быстрый бутстрап, отсутствие заморочек с архитектурой, унифицированные методы разработки, поддержка коммьюнити.
Однако сложные специфические решения требуют как раз персонализированного подхода и гибкости, которую фреймфорк не в состоянии обеспечить. Здесь приходится либо изобретать что-то свое, т.к. решение в корне меняет архитектуру, предложенную фреймворком.
Анализируя реальные задачи, с которыми я сталкивался, в 90% случаев приходил к выводу, что использование фреймворка излишне. Все делалось проще и понятнее на обычной Java. Фреймворк добавлял магии, и только сильно запутывал код.
Однако сложные специфические решения требуют как раз персонализированного подхода и гибкости, которую фреймфорк не в состоянии обеспечить. Здесь приходится либо изобретать что-то свое, т.к. решение в корне меняет архитектуру, предложенную фреймворком.
Анализируя реальные задачи, с которыми я сталкивался, в 90% случаев приходил к выводу, что использование фреймворка излишне. Все делалось проще и понятнее на обычной Java. Фреймворк добавлял магии, и только сильно запутывал код.
Извините, но мне кажется вы смешиваете здесь две разных проблемы:
1. Писать всё самому или использовать фреймворк
2. Опыт в использование конкретного фреймворка
Автор статьи придерживается мнения, что часто лучше самому запрограммировать всё с нуля. Странно правда, что при этом он использует сервлеты, а не пишет собственное решение.
Ошибочное мнение многих начинающих разработчиков — «легче написать самому, чем разобраться в том, что уже сделали другие».
Хороший фреймворк — это ни что инное как эсенция годами накопленного опыта разработчиков специализирующихся в этой области.
Конечно же фреймворк не даёт 100% решения определённой задачи, но разработчик с опытом работы в этом фреймворке, используя его как конструктор намного быстрее и качественнее решит поставленную задачу.
Тут нет однозначного ответа, всё зависит от поставленной задачи, но в разработке веб-систем, я думаю использование фреймворков не оспаримо. Иначе надо всё таки быть совсем крутым и самому написать сервлет-контайнер на коленке аля myTomCat.
1. Писать всё самому или использовать фреймворк
2. Опыт в использование конкретного фреймворка
Автор статьи придерживается мнения, что часто лучше самому запрограммировать всё с нуля. Странно правда, что при этом он использует сервлеты, а не пишет собственное решение.
Ошибочное мнение многих начинающих разработчиков — «легче написать самому, чем разобраться в том, что уже сделали другие».
Хороший фреймворк — это ни что инное как эсенция годами накопленного опыта разработчиков специализирующихся в этой области.
Конечно же фреймворк не даёт 100% решения определённой задачи, но разработчик с опытом работы в этом фреймворке, используя его как конструктор намного быстрее и качественнее решит поставленную задачу.
Тут нет однозначного ответа, всё зависит от поставленной задачи, но в разработке веб-систем, я думаю использование фреймворков не оспаримо. Иначе надо всё таки быть совсем крутым и самому написать сервлет-контайнер на коленке аля myTomCat.
> Автор статьи придерживается мнения, что часто лучше самому запрограммировать всё с нуля. Странно правда, что при этом он использует сервлеты, а не пишет собственное решение.
Есть разница между фреймворком и библиотекой. Чаще всего фреймворк следует принципу «don't call me, I call you», т.е. решение представляет собой конфигурацию + разрозненные куски кода, реализующие тот или иной функционал, а фреймворк — это core. Такой подход накладывает искусственные ограничения на «правильное» написание кода (так вот можно, а вот так нельзя — фреймворк не поймет), и добавляет в решение неявной «магии», при сомнительном выигрыше. При библиотечном же подходе разработчик полностью в явную контролирует все, что творится у него в рантайме, всю конфигурацию, жизненный цикл объектов, все вызовы API.
Если мне нужен сервлет контейнер, я подключаю Jetty как embedded библиотеку. Все создается и конфигурируется прямо в коде. Jetty очень хорошо «модулеризирован»: весь функционал разбит по разным jar-ам, которые можно подключать по надобности.
> Ошибочное мнение многих начинающих разработчиков — «легче написать самому, чем разобраться в том, что уже сделали другие».
Чаще всего я вижу другой подход: «будем использовать Spring, потому что все так делают». Начинающий разработчик скачивает tutorial (какой-нить Spring+Hibernate+Struts), и делает скелет приложения. Неважно, что из функционала спринга он использует пару бинов и коннекшн к базе данных, из Hibernate — две связанных таблицы, а из Struts — jsp.
Другой вопрос — сможет ли начинающий разработчик с нуля написать адекватную систему? Поэтому в техзадании требуют фреймворк, чтобы облегчить поддержку кода, т.к. фреймворк дает определенную методологию разработки («рельсы»). Реально же из начинающих разработчиков, программирующих на фреймворках, я мало видел людей, полностью понимающих основные концепты. Для большинства документация к фреймворку — это магическая книга, где чтобы сделать ту или иную вещь нужно найти заклинание и вставить его в код.
> Хороший фреймворк — это ни что инное как эсенция годами накопленного опыта разработчиков специализирующихся в этой области.
Вот здесь позвольте не согласиться. Во-первых, фреймворк — это определенная идея, обернутся в реализацию. Это совсем не значит, что эта идея, пусть даже и красивая, действительно необходима и удобна в использовании. Как правило у всех красивых идей бывает обратная сторона. И преимущества идеи с лихвой могут покрываться «побочными эффектами», вызываемыми этой идеей.
Во-вторых, создатели фреймворка занимаются исключительно фреймворком и как правило не пишут приложений, а посему далеки от реальных потребностей разработчика.
В-третьих, всегда существуют побочные эффекты, вызванные различными причинами: от «неверного» использования до конфликта jar-ов. Значительная часть усилий тратится на «я написал как надо, а у меня не работает (как я хочу)» и решение проблем самого фреймворка. Порой простую вещь сделать на порядок сложнее с фреймворком, чем на голой java.
> но в разработке веб-систем, я думаю использование фреймворков не оспаримо.
Отсюда и пошли все фреймворки и это их основное назначение.
P.S. Я не считаю фреймворки абсолютным злом. Просто перед использованием каждого из них разработчик должен задуматься над вопросами:
— какой функционал мне нужен и смогу ли я обойтись без него?
— не проще ли будет и смогу ли я написать это все без фреймворка?
— есть ли библиотеки, реализующие данный функционал?
— действительно ли преимущества фреймворка использования покроют недостатки?
Есть разница между фреймворком и библиотекой. Чаще всего фреймворк следует принципу «don't call me, I call you», т.е. решение представляет собой конфигурацию + разрозненные куски кода, реализующие тот или иной функционал, а фреймворк — это core. Такой подход накладывает искусственные ограничения на «правильное» написание кода (так вот можно, а вот так нельзя — фреймворк не поймет), и добавляет в решение неявной «магии», при сомнительном выигрыше. При библиотечном же подходе разработчик полностью в явную контролирует все, что творится у него в рантайме, всю конфигурацию, жизненный цикл объектов, все вызовы API.
Если мне нужен сервлет контейнер, я подключаю Jetty как embedded библиотеку. Все создается и конфигурируется прямо в коде. Jetty очень хорошо «модулеризирован»: весь функционал разбит по разным jar-ам, которые можно подключать по надобности.
> Ошибочное мнение многих начинающих разработчиков — «легче написать самому, чем разобраться в том, что уже сделали другие».
Чаще всего я вижу другой подход: «будем использовать Spring, потому что все так делают». Начинающий разработчик скачивает tutorial (какой-нить Spring+Hibernate+Struts), и делает скелет приложения. Неважно, что из функционала спринга он использует пару бинов и коннекшн к базе данных, из Hibernate — две связанных таблицы, а из Struts — jsp.
Другой вопрос — сможет ли начинающий разработчик с нуля написать адекватную систему? Поэтому в техзадании требуют фреймворк, чтобы облегчить поддержку кода, т.к. фреймворк дает определенную методологию разработки («рельсы»). Реально же из начинающих разработчиков, программирующих на фреймворках, я мало видел людей, полностью понимающих основные концепты. Для большинства документация к фреймворку — это магическая книга, где чтобы сделать ту или иную вещь нужно найти заклинание и вставить его в код.
> Хороший фреймворк — это ни что инное как эсенция годами накопленного опыта разработчиков специализирующихся в этой области.
Вот здесь позвольте не согласиться. Во-первых, фреймворк — это определенная идея, обернутся в реализацию. Это совсем не значит, что эта идея, пусть даже и красивая, действительно необходима и удобна в использовании. Как правило у всех красивых идей бывает обратная сторона. И преимущества идеи с лихвой могут покрываться «побочными эффектами», вызываемыми этой идеей.
Во-вторых, создатели фреймворка занимаются исключительно фреймворком и как правило не пишут приложений, а посему далеки от реальных потребностей разработчика.
В-третьих, всегда существуют побочные эффекты, вызванные различными причинами: от «неверного» использования до конфликта jar-ов. Значительная часть усилий тратится на «я написал как надо, а у меня не работает (как я хочу)» и решение проблем самого фреймворка. Порой простую вещь сделать на порядок сложнее с фреймворком, чем на голой java.
> но в разработке веб-систем, я думаю использование фреймворков не оспаримо.
Отсюда и пошли все фреймворки и это их основное назначение.
P.S. Я не считаю фреймворки абсолютным злом. Просто перед использованием каждого из них разработчик должен задуматься над вопросами:
— какой функционал мне нужен и смогу ли я обойтись без него?
— не проще ли будет и смогу ли я написать это все без фреймворка?
— есть ли библиотеки, реализующие данный функционал?
— действительно ли преимущества фреймворка использования покроют недостатки?
Мне кажется, что автор прав в том, что фреймворки — палка о двух концах, и, прежде чем использовать их, следует 7 раз отмерить, насколько плюшки фреймворка покрывают его тяжесть, ограничения и требования изучения его специфики. У меня, например, сейчас в поддержке проект с Seam, в котором не «5 мегабайт библиотек», а 35, причем реально используется в лучшем случае 3-5% их возможностей. Можно было сделать все то же самое, но без Seam (и того, что тянется с ним в зависимостях) вообще…
С другой стороны, всем понятно, что с нуля писать всё — разве что в качестве «поиграться» пока не надоест либо в маленьких проектах. Лично мне нравится пользоваться не фреймворками, «окружающими» мое приложение (т.е. моё приложение внутри фреймворка), вместо этого предпочитаю, чтобы фреймворки были внутри приложения. Т.е., использую только утилитарные вещи, которые подключаются и делают какую-либо ограниченную часть функций, по возможности не затрагивая другие слои приложения. Например, классический Hibernate берет на себя всю работу с БД, и заставляет разбираться с его спецификой только для операций с базой. При этом, например, получив при его помощи объект считанный из БД, при дальнейших операциях с этим объектом, про Hibernate можно забыть.
Несмотря на то, что тема статьи в общем и целом актуальна, конкретные примеры, на мой взгляд «ни о чём» — просто некий код, которого в любом проекте море. Ценность статьи, на мой взгляд — 0, комментарии полезнее и информативнее, чем статья…
С другой стороны, всем понятно, что с нуля писать всё — разве что в качестве «поиграться» пока не надоест либо в маленьких проектах. Лично мне нравится пользоваться не фреймворками, «окружающими» мое приложение (т.е. моё приложение внутри фреймворка), вместо этого предпочитаю, чтобы фреймворки были внутри приложения. Т.е., использую только утилитарные вещи, которые подключаются и делают какую-либо ограниченную часть функций, по возможности не затрагивая другие слои приложения. Например, классический Hibernate берет на себя всю работу с БД, и заставляет разбираться с его спецификой только для операций с базой. При этом, например, получив при его помощи объект считанный из БД, при дальнейших операциях с этим объектом, про Hibernate можно забыть.
Несмотря на то, что тема статьи в общем и целом актуальна, конкретные примеры, на мой взгляд «ни о чём» — просто некий код, которого в любом проекте море. Ценность статьи, на мой взгляд — 0, комментарии полезнее и информативнее, чем статья…
А теперь добавим в наше приложение пару-тройку (20-30) библиотек, которые знать не знают про наш контекст. Конструктор несколько увеличится в размере. Ну и нужно будет внимательно следить за порядком инициализации бинов. Ну а как же интерцепторы? Как сессию для работы с БД создавать? А транзакции? Кстати, о подключении к БД, куда мы положим настройки этого самого подключения?
Дальше, использование вашего контекста исключается переиспользование классов в других приложениях, т.к. все они будут завязаны на контекст.
А вообще, есть же picocontainer.com/. Есть множество IoC-контейнеров подходящих под разные задачи.
Дилетантская статья из серии о том, что пушки слишком долго перезаряжаются, чтобы стрелять из них по воробьям.
Дальше, использование вашего контекста исключается переиспользование классов в других приложениях, т.к. все они будут завязаны на контекст.
А вообще, есть же picocontainer.com/. Есть множество IoC-контейнеров подходящих под разные задачи.
Дилетантская статья из серии о том, что пушки слишком долго перезаряжаются, чтобы стрелять из них по воробьям.
Спасибо, правильная статья для прочистки мозгов. На мой взгляд для современных Java разработчиков важно понимать, что Spring и EJB не догма и не магия и все можно сделать руками.
Другой вопрос что конечно тут за кадром остается большое кол-во вопросов таких как startup/tear down, декларативное управление транзакциями/конектом, session/conversation scope и т.п.
Т.е. делать так в реальном приложении сейчас в общем довольно странно, но понимать что можно и так сделать и как все оно работает — очень полезно.
Другой вопрос что конечно тут за кадром остается большое кол-во вопросов таких как startup/tear down, декларативное управление транзакциями/конектом, session/conversation scope и т.п.
Т.е. делать так в реальном приложении сейчас в общем довольно странно, но понимать что можно и так сделать и как все оно работает — очень полезно.
рано или поздно свой велосипед превращается в убогое подобие «фреймворка» с костылями и прочими сладостями
Простите, это у меня мозг замылен к концу рабочей недели, или создание контекста упадет из-за отсутствия конструктора без аргументов?
Да, не сложно увидеть, что бОльшая часть того, что нам нужно от фреймворка делается десятком строк кода на коленке. Остальная часть фреймворка — это длинный хвост всяких странных фич, которые нужны раз в сто лет.
Однако есть и изъны у такого подхода — это коммандная разработка и перспективность. Использование готовых библиотек создает некий общий язык для разработчиков, приводит к выработке и закреплению хороших практик. Если каждый сядет писать свой DI, то вариантов реализаций будет столько же, сколько и разработчиков, и каждый будет считать свой вариант самый лучшим. Что касается перспективности — хорошие, популярные библиотеки имеют свойство обрастать всевозможными интеграциями и расширениями. Например JRebel понимает Spring, поймет ли он ваш «контейнер»? Ответ очевиден.
Так что такой подход работает только если вы работаете в одиночку, или остальные разработчики — это такие джуниоры, которые проглотят все, что им дадут. Если речь идет не о разовой поделке, а о серьезном проекте, то нужно делать ставки на популярные, качественные готовые компоненты.
Однако есть и изъны у такого подхода — это коммандная разработка и перспективность. Использование готовых библиотек создает некий общий язык для разработчиков, приводит к выработке и закреплению хороших практик. Если каждый сядет писать свой DI, то вариантов реализаций будет столько же, сколько и разработчиков, и каждый будет считать свой вариант самый лучшим. Что касается перспективности — хорошие, популярные библиотеки имеют свойство обрастать всевозможными интеграциями и расширениями. Например JRebel понимает Spring, поймет ли он ваш «контейнер»? Ответ очевиден.
Так что такой подход работает только если вы работаете в одиночку, или остальные разработчики — это такие джуниоры, которые проглотят все, что им дадут. Если речь идет не о разовой поделке, а о серьезном проекте, то нужно делать ставки на популярные, качественные готовые компоненты.
Sign up to leave a comment.
Строим веб-приложение на Java без JEE и Spring