badboychikРешил научиться писать Java EE приложения. Почитал, потыкал и пришел в ужас. Всё как-то урывками, сплошь недосказанности, уроки по какой-то узкой области или наоборот - даются исходники сложных проектов и разбирайся как хочешь, а там все в XML, везде неявные и запутанные взаимосвязи между бинами, сервлетами, антом и мавеном и т.д...

Это не касается хэлоуворлдов - сервлеты и JSP страницы писать легко, но это уже вчерашний день. Хочется аналитических и сравнительных материалов, чтоб сразу были указаны сильные и слабые стороны нескольких фреймворков, чтоб не набивать шишки самому , теряя время.

Перечислю основные непонятки:
1. Работа с БД. Так то понятен принцип ОRM, но удивляет объем ручной работы - приходится на каждую таблицу создавать класс Entity, расписывать аннотации, геттеры/сеттеры. Вроде как IDE имеют функции, упрощающие это, но все равно надо править и потом копаться в этих простынях - бинах-POJO-сущностях...
Вопрос №1 который нигде не освещен: что первично - БД или хибернейт? Если я начал проект с нуля и у меня активно по ходу дела изменяется структура БД, связи, то как мне синхронизировать с ней структуру классов-сущностей? Можно ли (пере)генерировать автоматически всю схему БД в классы и чтоб не потерялись свои методы? Или же наоборот - меняя сущности в яве можно ли (пере)создать таблицы в БД? Вот хороший урок по хиберу но тут ответа нет.
Поэтому еще вопрос - как пишутся системы где в БД 100-1000 таблиц?

2. Веб. Тут разброс огромный. В джентльменский набор знаний думаю должен войти Spring, JSP/JSF, Servlets.
Сравнения Wicket,Struts,Tapestry,Click и других - не нашел. Сам склоняюсь к Клику.
Вопрос №2 - можно ли начать писать на одной платформе (например просто сервлеты+JSF), а потом перенести на новую платформу (например Spring+Click) или придется переписывать 90% системы? Можно ли добавлять по отдельности технологии, например прикрутить JDBC а потом перенести на хибер? или потом хибер заменить на TopLink?
Интуицией чую что надо все переписывать, ведь нельзя на РНР перенести проект например с Zend на Kohana... Но вдруг какие то технологии в яве совместимы... Или для изучения каждого сочетания технологий надо начинать проект заново?

3. Серверы приложений. Тоже хотелось бы в одном месте прочитать чем каждый хорош и плох, про GlassFish vs. JBoss вроде немного понятно , но есть еще много всяких типа Jetty, Geronimo, IBM Websphere, Resin , WebLogic...
Вопрос №3 - переносимы ли JavaEE проекты между ними? Вроде как JavaЕЕ потому и стандарт, что должен обеспечивать переносимость, но не все серверы поддерживают эти стандарты... Видел такое мнение:
авторА кто-нибудь из коллег разработчиков работал с glassfish и jboss на продакшене?

Я почему интересуюсь — в последнее время у меня ощущение, что jboss выпущен в open source только с одной целью — чтобы пользователи переходили на коммерческую версию и платили бабки за поддержку. Очень, очень он кривой. И коммьюнити у него кривое. На многие вопросы в коммьюнити нет ответа, и никто его не знает, и бесплатно не скажет.

А вот glassfist с какой стороны не посмотришь — везде гладкий и красивый, и все у него здоровски сделано, и на тестовом серваке хорошо себя ведет.

Опять же, оба представляет собой EJB-контейнер, так что проблем с портированием приложений возникнуть не должно.

4. Всяческие мавены-анты-Gitы-svnы. Опять же - надо ли сразу писать с ними или можно опосля добавить в готовый проект. По мавену нашел

Нашел книжку, "Разработка JavaEE-приложений в Нетбинсе", судя по оглавлению, должна снять многие вопросы, буду штудировать, параллельно с "JavaEE 6 manual". Короче, изучать еще много, но пока волнует вот это.

Я лублу WPF

1. Написание сущностей - так много?оО. Если да пробуйте переходить куда нить еще ;) На худой конец попробуйте Spring Roo - советую: неплохой кодогенератор.
Если мыслить совсем уже ООП, то конечно, можно создать сущности, а потом хибер на основе их может поднять базу(см hibernate.hbm2ddl.auto) , но я вам скажу, что начинать знакомтсо работы сбд с хибера - это извращение. Начать хотя бы с понимания JPA. И вообще в небольших проектах хибер можно не использовать...а можно и в больших не использовать ) Другими словами - надо понимать..минусы и плюсы его.

2.Зависит от вашей архитектуры, если грамотно применять паттерн разработки MVC или MVP - потребуется менять гораздо меньше. Но полной приемственности конечно нет.
Выбор платформы....мне очень понравился wicket - в html коде никакого "постороннего" кода ;) легкий, при разработке похож на swing; если нужно проектировать сложный графический интерфейс на вебе - можно глянуть в сторону zkoss.

3. Если при разработке вы понимаете что такое DI и программируя - мыслите интерфейсами, проблем особых не возникнет при "переносе"

4.Если понимаете что такое classpath и тд то конечно лучше с maven`ов сразу связаться - значительно облегчает жизнь Ант - по желанию.

5.