Как повысить производительность при разработке веб-приложений на основе Java EE

Ответ 1

Я считаю, что Java-стек Java EE на самом деле очень хорош. Существует несколько причин, объясняющих низкую производительность Java EE:

• Будучи "корпоративным стеком", он часто используется для создания скучных, уродливых, "достаточно хороших" приложений и, в общем, предприятия, как правило, не привлекают отличных разработчиков, которые любят программирование, а также думают и заботятся о том, что они делают. Качество программного обеспечения в корпоративном мире невелика.
• Будучи корпоративным стеком, где деньги, поставщики программного обеспечения пытаются что-то продать им. Они создают огромные, сложные и дорогостоящие решения не потому, что они хороши, а просто потому, что они могут продавать их предприятиям.
• Предприятия часто очень склонны к риску и все, что им лучше, "стандартизировано". Стандарты создаются либо после того, как некоторые технологии оказались успешными или раньше. В обоих случаях это плохо для предприятий (и Java). Предприятия в конечном итоге используют либо хорошие технологии слишком поздно, либо просто неудачные технологии. Последний случай также очень опасен, потому что он создает ложное представление о том, что технология (в противном случае - полный отказ) должна быть хорошей, если она стандартизирована, и все ее используют.
• Исторически сложилось так, что платформа Java EE, похоже, привлекла большое количество астронавтов и разработчиков архитектуры в крупных компаниях, продвигаемых для архитекторов, единственная цель которых заключалась в создании большего количества слоев, больше фреймворков, больше абстракций и большей сложности.

Не то, что нет хороших инструментов и фреймворков Java; его слишком много плохих, слишком много слишком переработанных, слишком много бюрократических процессов и методологий, слишком много бесполезных стандартов.

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

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

Мой совет:

• Не используйте технологию только потому, что ее стандарт, потому что каждый использует ее, или потому, что ее официально рекомендовали Sun. Используйте технологию, только если вы лично считаете ее лучшим инструментом для своей работы. Таким образом, вы можете отказаться от таких технологий, как JSF, JSP, веб-службы, JMS, EJB, JTA, OSGi, MDA.
• Держите его простым, используйте здравый смысл, задавайте все вопросы. Вам действительно нужно публиковать свои объекты для удаленного доступа? Вам действительно нужно создать еще один слой абстракции, чтобы вы могли переключиться с Hibernate на TopLink? Вам действительно нужно конвертировать ваши данные в/из XML десять раз каждый раз, когда вы в них нуждаетесь? Вам действительно нужна схема XML? Вам действительно нужно все, чтобы настраиваться, взаимозаменяемы? Во время выполнения? Не разработчиками?
• Держите процесс простым. Be agile. Вам действительно нужна эта документация? Вам действительно нужно описать каждый экран в огромной таблице, одобрить его, ввести в какой-то самодельный инструмент и затем создать JSP? У вас есть компетентные программисты или вы все сначала разрабатываете, а программисты только "переводят" на Java?
• Конструкция HTML WYSIWYG не работает.
• Графическое программирование вообще не работает. Это включает UML в качестве чертежа и UML как язык программирования, MDA, схемы чертежей страницы. Генерация кода плохая.
• Никогда создать структуру перед ее использованием, всегда собрать структуру.
• Предпочитают фреймворки, которые имеют только небольшую конфигурацию XML.
• Стремитесь к низкому количеству LOC. Посмотрите на фактические символы в коде. Важен ли каждый персонаж? Думать. Что вы можете сделать, чтобы уменьшить ваш код? Вам нужен этот класс? Что оно делает? Зачем вам это нужно?
• Тестирование - это не священная корова; вам не нужно 100% -ное покрытие. Испытайте только то, что имеет смысл. Если его трудно проверить, упростите его; или вообще не проверяйте его. Не проверяйте визуальный внешний вид.

И, наконец, некоторые конкретные рекомендации Java:

• Для уровня представления попробуйте Tapestry. Почему я люблю это? Потому что с Tapestry вы можете создать красивый код. Он разработан специально для этого, так что ваш код может быть красивым. Ваш код. Красивым я имею в виду все, что имеет значение - его короткое, легко меняющееся, легко читаемое, легко создающее ваши абстракции и все же гибкое, оно не пытается скрыть тот факт, что вы развиваетесь в Интернете. Конечно, его все еще вы, который делает ваш код красивым.
• Не используйте Hibernate, особенно для CRUD и больших приложений. Не беспокойтесь о JPA. Это не серебряная пуля, хотя с ORM вы всегда будете торговать одним набором проблем с другим.
• Немного Spring, вам не нужно многого, так как вы тщательно избегали всех ловушек Java EE. Используйте инъекции зависимостей экономно.
• После всего этого вы можете найти язык Java слишком многословным и не очень полезным при абстрагировании от копирования или вставки кода. Если вы хотите поэкспериментировать, попробуйте Scala. Проблема в том, что основной точкой продаж Scala является то, что вы получаете все преимущества современных языков, сохраняя при этом безопасность типов, и в то же время нет надежной поддержки IDE. Будучи привыкшим к супер-охлаждению Java IDE, не имеет смысла переключаться на Scala, если поддержка IDE не стабильна и надежна. Недостаточно достаточно стабильного.

Ответ 2

Рамки, такие как Spring, Hibernate, Wicket, безусловно, помогают упростить и ускорить веб-разработку, поскольку они обеспечивают высокую степень тестируемости и очень хорошо интегрируются. Но этого недостаточно для достижения производительности RoR, даже если у вас есть хороший набор методов разработки. Существует еще слишком много технических материалов и требуется сантехника.

Grails - это, возможно, недостающая часть на этой картинке, чтобы приблизиться к RoR. Это мое следующее экспериментирование.

Кстати, мой опыт MDA противоречит повышению производительности, поэтому я не буду упоминать их (на самом деле MDA убивала нашу производительность).

Ответ 3

Javarebel может значительно сократить время, затрачиваемое на веб-разработку, используя Java.

Позвольте мне привести здесь официальный сайт:

JavaRebel - это JVM-плагин (-javaagent), который позволяет сразу увидеть изменения в коде без необходимости повторного развертывания приложения или выполнения перезапуска контейнера. Если вы устали наблюдать за просмотром журналов и хотите увидеть свои изменения, чтобы вы могли продолжать работу - JavaRebel - ваш новый лучший друг.

Ответ 4

Один важный момент при обсуждении производительности Java EE: вы должны использовать Java EE 5 и EJB3.x, поскольку они обеспечивают новый уровень производительности (и функциональности) по сравнению с предыдущими версиями.

Пребывание в стандартных спецификациях Java EE абсолютно важно, например. использование Hibernate вместо JPA не выгодно для производительности. Нет никаких ограничений, чтобы вернуться к функциям Hibernate при использовании JPA, но, используя Hibernate вместо JPA, вы заблокированы одним провайдером непрерывности без дешевого выхода. Вся идея использования стандартов одна и та же: концептуальная гибкость (путем подключения различных реализаций) с доступной расширяемостью (с использованием проприетарных расширений, если это абсолютно необходимо). Java EE 5 и EJB3 - это огромные шаги в этом направлении. Конечно, вы хотите свести к минимуму любые проприетарные функции, но если некоторые из них кажутся абсолютно необходимыми, это хороший признак того, что они будут частью спецификации в следующей версии...

Основными препятствиями для производительности Java EE являются корпоративная направленность (предлагает намного больше, чем это необходимо для большинства проектов) и в ее наследии (обратная совместимость). Кроме того, в презентационном уровне с JSF и государственным управлением также нужно сделать еще многое - посмотрите на JSR-299, чтобы решить эти проблемы среди других улучшений.

Ответ 5

Часто упоминалось, что RoR и подобные структуры на основе динамических языков - более продуктивные среды, но мне действительно интересно узнать, имеются ли жесткие данные для поддержки этого. Это было бы нелегко, так как нужно быть уверенным, что она не сравнивает яблоки с апельсинами. Необходимо учитывать такие вещи, как тип проекта (веб-2.0, корпоративное приложение) и размер группы. Однако для небольших проектов более чем очевидно, что такие структуры действительно намного более эффективны, чем Java EE. Итак, это короткий список аргументов, используемых для поддержки этого и того, что вы можете сделать для них в мире Java.

Ruby - более интуитивный и лаконичный язык. Вы можете сделать то же самое с гораздо меньшим количеством кода.

Я не думаю, что вы можете иметь одно и то же в Java, если, конечно, вы не используете динамический язык, который работает в JVM (JRuby, Scala, Groovy). В противном случае ваша IDE может помочь. В Jave IDE является важным инструментом, и он вернет вам деньги, если вы научитесь хорошо использовать его (генерация кода, фрагменты, рефакторинг). На самом деле есть много вещей, которые вы можете сделать с Java IDE, которые просто невозможно сделать с помощью Ruby или Python IDE. Кроме того, у вас есть преимущества статического типизированного языка. Это может занять больше времени, но это поможет вам избежать распространенных ошибок.

Ruby гораздо интереснее использовать. Делает разработчика более счастливым и продуктивным.

То же, что и выше. По-моему, очень субъективный аргумент.

Контракт над конфигурацией делает вещи быстрее

Рамка инъекции зависимостей, например Spring или Guice, может помочь

Леса, MVC уже есть для вас.

Снова рамки Java MVC могут помочь

Базы данных упрощаются. Загружать элементы базы данных в виде объектов. Может менять базу данных на лету.

Hibernate, iBatis или другая структура ORM могут помочь. С Hibernate Tools вы можете добиться аналогичной функциональности с тем, что у вас есть в RoR с yml файлами

Загрузка новых модулей мгновенно

Maven или Ant Айви может помочь

Простое развертывание для тестирования

Ваша IDE или Jetty могут помочь. На самом деле отладка проще с Java

Тестирование интегрировано с каркасом. Использование макетных объектов облегчает тестирование

Рамка инъекций зависимостей может помочь с макетными объектами. JUnit был пионером подразделения. Я не думаю, что Java легче тестировать.

Ответ 6

Grails - это система Java Webapp, очень сильно смоделированная после Ruby on Rails, с аналогичными принципами (DRY, CoC) и приростом производительности, но на основе существующих фреймворков Java (Spring, Hibernate, несколько других).

Я работаю над поисковым проектом с использованием Grails в течение нескольких недель (без предыдущего опыта в Grails или Groovy), и я очень впечатлен. Есть несколько грубых краев - он не настолько зрелый, как RoR, но вы можете быстро получить результаты, и никогда не возникает ощущение, что структура мешает вам.

Возможно, это лучше всего проиллюстрировано на этом конкретном примере: я хотел отредактировать 2D-массив объектов домена в сетке на одной веб-странице и обнаружил, что автоматическое сопоставление полученных данных запроса HTML с объектами домена (предоставляется Spring MVC, я полагаю) имел ошибку, из-за которой некоторые данные были сопоставлены с неправильными объектами. Я огляделся по Сети в течение часа, но, видимо, никто не столкнулся или не решил проблему. В конце концов я решил отказаться от автоматического сопоставления и сделать это "вручную", а затем обнаружил, что мне понадобилось не более 10 строк кода...

Ответ 7

Я бы определенно пошел на Spring вместе с Hibernate для материала, связанного с постоянством.

Почему Spring?

Преимущество использования Spring вместо другой структуры заключается в том, что философия Springs должна быть " неинвазивной". Обычно, когда вы используете фреймворк, скорее всего, вы начнете зависеть от этой структуры, которая может быть плохой проблемой, если приложение считается запущенным в течение более длительного времени, когда вы также должны выполнять обслуживание и т.д. Spring использует так называемый шаблон "Инверсия управления" (IoC). В принципе, ваш код не может (может, но не обязательно) называть Spring, но Spring позвонит вам (принцип Голливуда: "не называй меня, я тебе позвоню" ). Например, вы можете использовать обычные POJO (обычные старые объекты Java), и вам не нужно наследовать ни один из связанных с каркасом классов/интерфейсов. Другой большой проблемой (если не самой большой) в разработке программного обеспечения являются зависимости. Вы будете бороться за то, чтобы сократить их как можно больше, так как они сделают вашу жизнь более трудной (особенно в обслуживании позже). Spring значительно уменьшает зависимости между вашими компонентами, управляя созданием компонентов через файлы конфигурации и шаблоном впрыскивания. Я не хотел бы продолжать, самое лучшее, что вы начинаете читать некоторые уроки на официальном Spring сайте. Первоначально это может потребоваться некоторое время в понимании, но как только вы его получите, вы получите много преимуществ.

Ответ 8

Так как Jython 2.5 вы можете использовать django для удовлетворения перечисленных вами требований. Очень легко создавать военные файлы из проектов django и развертывать их на серверах приложений J2EE.

Ответ 9

Просто хотел передать другую идею... вы можете использовать JRuby и Rails (аналогично предыдущему комментарию о Django и Jython).

Если вы используете JRuby с Rails и JRuby Rack (и, возможно, некоторые другие утилит... Я не был тем, кто фактически начал интеграцию), вы можете развернуть дополнения JRuby Rails в существующем веб-приложении Java. У нас есть устаревшее JSP-приложение, развернутое с Tomcat, и теперь начинают добавлять новые страницы с помощью Rails только с этой настройкой (в дополнение к расширению JSP-стороны, когда это необходимо). До сих пор он был довольно успешным, хотя у нас нет каких-либо крупных страниц с высоким трафиком, реализованных в Rails, поэтому я не знаю, насколько он масштабируется.

У нас есть полный доступ к сеансу и даже настроены механизмы для вызова JSP из Rails-страниц (например, существующие JSP файлы верхнего и нижнего колонтитула). Требуется некоторое усилие, проб и ошибок, чтобы полностью интегрировать 2, но если Rails и JRuby являются опцией, я настоятельно рекомендую его (как личный поклонник Ruby).

В JBoss Seam балуется коллега, который является основой Гавина Кинга (парня, который привел нас в Hibernate), который должен был подражать Rails. Увидев оба, я чувствую, что Rails намного легче разрабатывать с помощью.

Ответ 10

Используйте AOP (аспектно-ориентированное программирование) для сквозных аспектов, таких как ведение журнала, авторизация и т.д. Вы можете использовать Spring AOP или AspectJ. Это делает беспорядок кода свободным и поддерживаемым.

Ответ 11

Я использовал Jboss Seam в течение последних нескольких лет и считаю, что это очень продуктивный способ разработки в Java EE (используя EJB3, Hibernate, Facelets). Я также делаю нечетный бит PHP-кодирования на стороне и могу честно сказать, что я более продуктивен с Seam (хотя это, вероятно, также указывает на мои навыки PHP.)

Для меня пара основных моментов:

• Горячее развертывание кода (абсолютное обязательное условие)
• DRY с Facelets
• Настройка на основе аннотаций
• Обширные вставные компоненты (особенно ajax4jsf)
• Поддержка IDE из инструментов Jboss

В среде IDE и из командной строки есть инструменты для создания скелетного кода аналогично RoR.

Ответ 12

Я пошёл бы с Поднимите фреймворк, написанный в Scala. Вы увидите большой прирост производительности, просто переключившись на Scala. Scala также очень стабилен, и очень легко вызвать код Java из вашего кода Scala. Не только это, но и очень похоже на Java, но с некоторыми дополнительными функциями. Для некоторых примеров вы должны обратиться к 5 Вещи, которые разработчик Java должен знать о Scala. Twitter переместит часть его кода на Scala.

Вы никогда не будете "застревать" на куске кода, потому что можете просто подумать о том, как вы это сделаете в Java и написать аналогичный код. Функции и исполнители первого класса дадут вам еще больший прирост производительности и оба будут в Scala. Scala, конечно, статически типизирован и имеет производительность, похожую на Java.

Я приведу автора рамки Lift для его описания:

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

• Приморские высокоуровневые сеансы и безопасность. Rails fast flash-to-bang.
• Django "больше, чем просто CRUD"
• Конструкция шаблона с дизайном Wicket (см. вид на лифте
  Во-первых)

И потому, что приложения Lift написанный в Scala, элегантный новый JVM языка, вы все равно можете использовать свои любимые библиотеки Java и ваш любимый контейнер сервлетов. использование код, который вы уже написали, и развернитесь в контейнер, который вы уже сконфигурировано!

Ответ 13

Некоторые основные правила:

• Извлеките сервер приложений - ОГРОМНАЯ победа в повороте и качестве. Храните веб-контейнер, если вам нужно, но настройте все в Spring и/или Hibernate, чтобы web.xml был минимальным.

• Протестируйте все, что вы теперь можете сделать из-за шага 1 (не требуется развертывание разворачиваемых XML файлов или генерация кода: все уже настроено в разработке).

• Используйте Wicket для реализации своего веб-уровня - больше никому не нужен JSP; Wicket в 10 раз эффективнее плюс легко тестируется (см. Шаг 2).

• Использовать SCRUM и гибкие методологии разработки

В результате производительность Java достигает 4GLs - мы в Atomikos имеем несколько проектов миграции, которые нам понравились. Поскольку мы перешли с платформ 4GL на Java/Java EE, мы могли бы сравнить оценки в обоих.

Также см. это сообщение в блоге: http://blog.atomikos.com/?p=87 a >

НТН

Гай

Ответ 14

Ну, я на самом деле не парень Java, поэтому я не могу сказать много, кроме... JSF

Мы пытались использовать его в течение некоторого времени, и это было катастрофой. Алмонт все шаги основы должны были пройти с большим количеством боли, без документации, без примеров, без знания сообщества. Мы использовали один плагин для Eclipse (Exadel Studio), мы рассмотрели несколько других фреймворков JSF, все они были несовместимы и плохо документированы. По сути, из всех тех, что мы пробовали, только инфраструктура Sun (забыли свое имя на основе NetBeans) могли создать новый JSF-проект, даже готовый из коробки. Остальные требовали много дней конфигурации apache и других вещей, которые для неопытного человека - настоящая проблема (хотя я ей это удалось).

Наша команда потратила несколько месяцев на то, что было сделано через несколько недель с ASP.NET. Люди были неопытными в JSF и ASP.NET.

Если экосистема JSF по-прежнему так плоха, как в 2007 году, я бы рекомендовал ее вообще избегать, производительность в любом случае не может быть и речи. Может быть, придерживаться JSP или что-то, что было проверено временем и хорошо развито?