Які плюси та мінуси різноманітних веб-фреймворків Java? [зачинено]

Я розглядаю можливість створити власний веб-сайт за допомогою Java і намагаюся вирішити, який фреймворк використовувати. Однак швидкий пошук фреймворків Java повертає більше 50 на вибір!

Мій веб-сайт просто буде для мого власного задоволення від його створення на самому початку, але якщо він стане популярним, було б добре для нього мати певну масштабованість або, принаймні, мати можливість переробити для цього.

Які основні відмінності між більш популярними фреймворками? Чи бувають випадки, коли один значно перевершує інші? Наприклад, корпоративні програми з великим трафіком порівняно з малими додатками з низьким трафіком. Мені також цікаво, чи набагато легше вчитися та використовувати, ніж інші.

Хтось має досвід роботи з деякими з цих фреймворків і може дати рекомендацію? Чи сама кількість варіантів просто служить попереднім попередженням, щоб уникнути веб-розробки на основі Java, де це можливо?

Я досить широко використовував Tapestry 3 , Wicket , Echo та JSF . Я справді рекомендую вам переглянути їх і вибрати той, який здається вам найпростішим, і максимально відповідати способу, яким ви віддаєте перевагу працювати.

З них мені було найзручніше працювати з Wicket завдяки легкому характеру складання компонентів та простоті шаблонування сторінок. Це відбувається вдвічі, тому якщо ви використовуєте власний db-код замість Hibernate чи якийсь інший фреймворк (я ніколи не був повністю задоволений програмою Wicket Hibernate або Spring Integration).

Echo - це чудово, якщо ви не проти написати весь свій макет на Java. Я знаю, що зараз інакше, але я все ще думаю, що продукт обслуговує досить вузьку нішу. Здається, вони змінюють модель розвитку з кожним серйозним випуском.

Гобелен - чудовий виріб, але, очевидно, він сильно відрізняється від інших з точки зору моделі розвитку, оскільки ним керує в основному один чувак. Говард Льюїс Шіп, без сумніву, досить розумний, але я розчарований їхнім рішенням забути про зворотну сумісність з кожним випуском. Знову ж таки, для ваших потреб це може не мати значення, і я завжди вважав, що вироби з гобеленів приємно працювати проти них.

JSF випускається роками і досі відчуває себе як щось, що створив хлопець Struts, щоб вирішити всі проблеми Struts. Насправді не розуміючи всіх проблем із Struts. Він все ще має незавершене відчуття, хоча продукт, очевидно, дуже гнучкий. Я використовую це і маю певну прихильність до нього, з великими надіями на його майбутнє. Я думаю, що наступний випуск (2.0), який буде представлений у JEE6, справді внесе його у свої права, з новим синтаксисом шаблону (подібним до Facelets) та спрощеною моделлю компонентів (користувацькі компоненти лише в 1 файлі ... нарешті).

І, звичайно, існує мільйон менших фреймворків та інструментів, які отримують свої власні послідовники ( Швидкість для основних потреб, необроблені JSP , Struts тощо). Однак я, як правило, віддаю перевагу компонентам, орієнтованим на компоненти.

Врешті-решт, я б порадив просто поглянути на гобелен, хвіртку та JSF і просто вибрати той, який вам найбільше подобається. Ви, мабуть, знайдете такий, який дуже швидко підходить вам так, як вам подобається працювати.

Мій улюблений - Spring Framework. З 2.5 Spring MVC - це ооооооооооооооооооооооооооооооооооооооооооооrnff, з новими анотаціями, домовленостями щодо особливостей конфігурації тощо

Якщо ви просто робите щось надзвичайно просте, ви можете просто спробувати використовувати звичайний API сервлетів і не турбуватися про фреймворк.

Я рекомендую компонований компонент Wicket . Це дозволяє вам писати веб-програму простим старим кодом Java, ви можете використовувати POJO як модель для всіх компонентів, і вам не потрібно возитися з величезними файлами конфігурації XML.

Я успішно розробив додаток для онлайн-банкінгу з Struts, коли виявив Wicket і побачив, наскільки легкою може бути розробка веб-додатків!

Нещодавно я почав використовувати Stripes Framework . Якщо ви шукаєте фреймворк на основі запитів, який дійсно простий у використанні, але не накладає жодних обмежень на те, що ви робите, я настійно рекомендую його.

Це схоже на підкоси, але це виходить далеко за рамки. Існують навіть деякі проекти плагінів, які дозволяють використовувати hibernate або jpa з дуже малою конфігурацією.

Є багато хороших фреймворків, хоча я чув, що хвіртка теж хороша, але я не використовував її.

Я ще не пробував, але я думаю

http://www.playframework.org/

має багато потенціалу ...

виходячи з php та класичного asp, це перший веб-фреймворк Java, який для мене звучить багатообіцяюче ....

ОНОВЛЕННЯ: Tapestry 5.2 вийшов, тож від нього не кинули, як раніше здавалося. Мій досвід роботи з гобеленом 4, а не 5, тому ваш пробіг може відрізнятися. Моя думка про гобелен змінилася з роками; Я змінив цю публікацію, щоб відобразити її.

Я більше не можу рекомендувати гобелен, як це робив раніше. Tapestry 5, здається, є значним покращенням, але моя головна проблема з Tapestry - не сама платформа; це з людьми, які стоять за цим.

Історично склалося так, що кожне велике оновлення версії Tapestry порушило зворотну сумісність із надзвичайними упередженнями, набагато більше, ніж можна було очікувати. Здається, це пов’язано з включенням нових методів кодування або технологій, які вимагають значного перероблення.

Говард Льюїс Шип (головний автор "Гобелену"), безумовно, є чудовим розробником, але я не можу сказати, що дбаю про його керівництво проектом "Гобелен". Розробка Tapestry 5 розпочалася майже відразу після відвантаження Tapestry 4. З того, що я можу сказати, Шип майже присвятив себе цьому, залишивши Tapestry 4 в руках інших авторів, які, на мою думку, не настільки здатні, як Ship. Після болісного переходу з «Гобелена 3» на «Гобелен 4», я відчув, що мене майже відразу покинули.

Звичайно, з виходом Tapestry 5, Tapestry 4 став застарілим продуктом. Я б не було проблем з цим , якщо оновлення шлях не був таким жорстоким знову . Тож зараз наша команда розробників знаходиться у досить незавидному становищі: ми могли б продовжувати використовувати по суті занедбану веб-платформу (Tapestry 4), зробити огидне оновлення до Tapestry 5 або повністю відмовитися від Tapestry і переписати наш додаток, використовуючи іншу платформу. Жоден з цих варіантів не дуже привабливий.

Габелен 5, нібито, написаний таким чином, щоб зменшити ймовірність поломки оновлення з цього моменту. Хороший приклад у класах сторінок: у попередніх втіленнях класи сторінок походили від базового класу, наданого Tapestry; несумісні зміни API у цьому класі були причиною великої кількості проблем зі зворотною сумісністю. У Tapestry 5 сторінки містять POJO, які під час роботи покращуються за допомогою "чарівного пилу феї гобеленів" за допомогою анотацій. Отож, доки діє контракт на анотації, зміни в Tapestry не вплинуть на класи ваших сторінок.

Якщо це правильно, тоді написання нової заявки за допомогою Tapestry 5 може вийти непогано. Але особисто мені не хочеться знову класти руку на пальник.

Відмова: Я працюю у Vaadin (раніше IT Mill)

Якщо ви робите щось RIAish, ви можете поглянути на Ваадіна . Це фреймворк AJAX, орієнтований на користувальницький інтерфейс, який для мене приємний у використанні (я сам походжу з PHP).

Існує тематичне дослідження, яке порівнює виконання одного і того ж додатка (тобто двох додатків з однаковим набором функцій) у Icefaces та Vaadin. У двох словах, там сказано, що розробка інтерфейсу була значно швидшою.

Незважаючи на те, що дослідження проводиться на вікі компанії, я можу запевнити, що воно об’єктивне, справжнє та правдиве, хоча я не можу змусити вас повірити мені.

Після довгого тестування різних рішень, для мене виявилося:

• Spring MVC для рівня презентації та контролера (однак НЕ Spring Spring Webflow, оскільки мої потоки засновані на ajax)

• jQuery для всіх речей на стороні клієнта

• Spring Security для, ну, аспекту безпеки

• Hibernate / JPA2

• Пристань заради продовжень (комета)

Один місяць надзвичайно крутої кривої навчання, але зараз я щасливий.

Я також хотів би відзначити, що я був лише на кроці від того, щоб пропустити всі ці речі на Java і навчитися Scala / LIFT. Що стосується мене, все в Java, що пов’язано з передовою веб-розробкою (комета, асинхронне спілкування, безпека (так, навіть із Spring Security!)), Все ще є трохи хакерською (докажіть мене неправильно за допомогою доказів, прохання !). Мені здається, що Scala / LIFT є більш нестандартним рішенням "все в одному".

Причина, чому я нарешті вирішив не їхати зі Скалою, - це

• як керівник проекту я повинен враховувати людські ресурси, і розробників Java набагато легше знайти, ніж розробників Scala

• для більшості розробників у моїй команді важко зрозуміти функціональну концепцію Scala, якою б вона не була

Ура Ер

Я теж чув хороші речі про Spring Framework. Взагалі, однак, я був вражений більшістю веб-фреймворків Java, які я розглядав (особливо Struts).

Для простого додатка я б точно розглянув можливість використання «необроблених» сервлетів та JSP і не турбувався про прийняття фреймворку. Якщо сервлети добре написані, в майбутньому, якщо додаток ускладнюється, перенесення на фреймворк має бути простим.

Мій вибір Wicket !!

Всі вони - ось у чому проблема ;-)

Я думаю, що для ваших скромних вимог вам просто потрібно закодувати сервлети або прості jsp-сторінки, які ви можете обслуговувати з сервера Tomcat. Я не думаю, що вам потрібен будь-який веб-фреймворк (наприклад, struts) для персональних даних веб-сайту

Вимовляти "використовувати JSF" трохи просто. Коли ви вирішили використовувати JSF, вам слід вибрати бібліотеку компонентів поверх неї. Чи будете ви використовувати MyFaces Tomahawk, Тринідад, Тобаго ( http://myfaces.apache.org/ )? А може, ICEfaces ( http://www.icefaces.org/ )? О, і якщо ви використовуєте ICEfaces, чи будете ви використовувати JSP або Facelets для своїх поглядів?

На мій погляд, важко сказати. Ніхто не має часу оцінити всі перспективні альтернативи, принаймні в проектах, над якими я працюю, оскільки вони недостатньо великі, щоб здійснити тримісячні етапи оцінки. Однак варто оглянути когось, хто має велику та активну спільноту і якого немає через рік. JSF існує деякий час, і оскільки його штовхає сонце, він буде навколо ще деякий час. Не можу сказати, чи це найкращий вибір, але він буде хорошим.

http://zkoss.org - хороший

Для сайтів із високим трафіком я б використовував фреймворк, який не керує станом клієнта на сервері - Wicket, JSF та Tapestry керують станом клієнта на сервері. Я б використовував ці фреймворки (Wicket - мій улюблений), лише якщо програма повинна бути більше схожою на настільну програму. Але я спробував би застосувати більш масштабований та простий підхід REST + AJAX.

Spring MVC є кандидатом, але з Spring MVC 3 у нього є дивна анотація, перевантажена модель програмування, яка не використовує переваги статичного набору тексту. Існують і інші потворні речі, такі як вихідні параметри, у методах у поєднанні зі звичайною віддачею, тому є два вихідних канали одного методу. Spring MVC також має тенденцію заново винаходити колесо, і вам доведеться налаштувати більше, ніж інші фреймворки. Я не можу порекомендувати Spring MVC, хоча він має кілька приємних ідей.

Grails - це зручний спосіб використовувати Spring MVC та інші усталені фреймворки, такі як Hibernate. Кодування - це цікаво, і ви швидко побачите результати.

І не забувайте, що API сервлетів з кількома маленькими помічниками, такими як FreeMarker для шаблонування, дуже потужний.

Я оцінив чимало фреймворків і Ваадіна ( http://vaadin.com/home ) аж до вершини.

Вам слід принаймні дати йому коротку оцінку.

На здоров’я!

Моїм вибором буде Wicket (для великих проектів та передбачуваної користувацької бази), GWT (для великих проектів, які в основному мають публічний доступ) або просто сервісна база (наприклад, Jersey / JAXRS) разом із набором інструментів JavaScript (для малих та середніх проектів) .

Я рекомендую Шов, особливо якщо вам потрібна наполегливість.

Див. Кілька коментарів щодо деяких програм програм Java (другий абзац):

http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html

Для швидкого та вигадливого графічного інтерфейсу ви можете використовувати JSF з бібліотекою Richfaces . Компоненти інтерфейсу Richfaces - прості у використанні та зручні посилання, доступні з демонстрацією коду на демо-сайті. Можливо, пізніше, коли на вашому сайті буде більше даних для обробки, і багато інформації буде перенесено в базу даних, ви можете підключити будь-яку структуру доступу до бази даних (ORM).

Не можу повірити, що ніхто не згадував GWT

Мій улюблений спосіб використовувати справді прості програми - Apache VelocityTools (VelocityLayoutServlet) з Velosurf ( http://velosurf.sourceforge.net ).

Для більш складних програм Spring MVC або Struts 2.

Спробуйте HybridJava - це набагато простіше, ніж будь-що інше.

Я б сказав, ваадін чи хвіртка