Что подучить по Java?

[Alex Ivanov]

Под "ипостасями" я имел в виду разные контроллеры и разные рендереры (Velocity вместо JSP), использование WebFlow и так далее. А что не так?

ну так и со струтсом никто не мешает use велоcиты и вебфлов, а спринг мвц совсем не старая и вряд ли провереннае, так скорее затык для спринг-фанов, ешо год назад тилес плугин был в стадии бета версии, multiaction controller - если памят не путает то же что то то ли не был раобочим то ли писался. Всего год назад. Лубой новый фрамеворк должен вносит инноватион - как gwt к примеру, или jsf те же. Спринг mvc - inovation zero, всег лиш тесное интегратион with spring, а struts со spring и так seamless integrataion.

"Затычка" в виде MVC была уже в версии 1.0. Это начало 2004 года, да недавно совсем
http://www.springframework.org/node/33

inovation zero пожалуй вообше не буду комментировать.

[Хирург]

"Затычка" в виде MVC была уже в версии 1.0. Это начало 2004 года, да недавно совсем
http://www.springframework.org/node/33

inovation zero пожалуй вообше не буду комментировать.

А зря, было бы интересно. я с ним толко не работал, только читал и поигрался. Но сейчас еще раз погуглил, ничего путного не нащёл, иначе бы фаны это раздули до небес. В чём же такая инновация спринг мвц по сравнению со струтсом, что стратс - это для лохов, а спринг мвц это "старое и проверное"? Такой же лоу левел фреймворк только в профиль. Остутствие надобности в наследованности как в струтсе или разные view - это не инновация, а просто гибкость, которая нафик не нужна в большинстве случаях. Использовать велосити со струтсом - нет проблем. Вон во втором стратсе не нужно наследоваться, и что все побежали? Нет, ибо это не ограничение, а всего лишь одно из возможных архитектурных решений, не больше не меньше.

[Alex Ivanov]

"Затычка" в виде MVC была уже в версии 1.0. Это начало 2004 года, да недавно совсем
http://www.springframework.org/node/33

inovation zero пожалуй вообше не буду комментировать.

А зря, было бы интересно. я с ним толко не работал, только читал и поигрался. Но сейчас еще раз погуглил, ничего путного не нащёл, иначе бы фаны это раздули до небес. В чём же такая инновация спринг мвц по сравнению со струтсом, что стратс - это для лохов, а спринг мвц это "старое и проверное"? Такой же лоу левел фреймворк только в профиль. Остутствие надобности в наследованности как в струтсе или разные view - это не инновация, а просто гибкость, которая нафик не нужна в большинстве случаях. Использовать велосити со струтсом - нет проблем. Вон во втором стратсе не нужно наследоваться, и что все побежали? Нет, ибо это не ограничение, а всего лишь одно из возможных архитектурных решений, не больше не меньше.

Я не говорил что Струтс для лохов! Это совершенно гениальный фреймворк, для 2000 года. Болеет того, 99% стандарт году этак в 2003-2005.
Просто с тех пор придумано дофига интересного.

Инновации в Spring MVC, самое на мой взгляд важное - не нужен весь этот "plumbing", бизнес обьекты (beans) можно пихать в request (session, application) scope и они сразу доступны на JSP страничке. Если это форма, обновления тоже идут автоматом, никаких ActionForms. Это реально очень удобно.
Тестировать тоже намного проше, у твоих классов нет завязки на servlet API - чистые бизнес обьекты с бизнес логикой. В Struts нужны mock objects, это не сахар.

Там еше много интересного, например я не знаю есть ли сейчас в Struts 1.x какой-то workflow...

Второй Struts как ты знаешь имеет мало обшего с первым, и он не очень популярен.

[Romeo]

Инновации в Spring MVC, самое на мой взгляд важное - не нужен весь этот "plumbing", бизнес обьекты (beans) можно пихать в request (session, application) scope и они сразу доступны на JSP страничке. Если это форма, обновления тоже идут автоматом, никаких ActionForms. Это реально очень удобно.
Тестировать тоже намного проше, у твоих классов нет завязки на servlet API - чистые бизнес обьекты с бизнес логикой. В Struts нужны mock objects, это не сахар.

+1

Саша, я бы еще добавил следующие пункты:

1) гениальная интеграция Spring Security, по-моему со второй версии Spring MVC
2) интеграция с остальными частями из Spring Portfolio:
a) IoC container
b) AOP - все cross-cutting concerns в AOP - код чище, включая фантастическую интеграцию с Spring transaction management
c) Sprig testing framework
d) etc.
3) Недавно Rod Johnson (создатель Spring) объявил, что следующий приоритет это усовершенствование Spring Web flow как неотъемлимой части Spring Portfolio (Spring web flow кстати очень неплохо интегрирован с JSF). Так что перспективы Seam могут быть существенно уменьшены в ближайшем будущем.

Кроме того, начиная со второй версии Spring и включая последнию (на сегодняшний момент 2.5.5) введены следующие инновации, которые существенно упрощают разработку веб приложений:

1) Ability to create own scopes
2) Annotation driven configuration including dependency injection
3) New annotated stereotypes have been added: @Component and other further stereotypes - annotated controllers, repositories, and services allowing for a more effective and compact configuration of standard multi-layered applications
4) Auto-detecting components in the classpath (easier application context configuration)
5) Ability to mix both annotation based configuration and XML configuration is a very powerful feature for configuring applications
6) Easier XML configuration - a number of new standard Spring XML namespaces have been added to significantly reduce the amount of XML configuration (for example, some Spring Security configuration files can now be reduced from hundreds lines to just a few lines)

Если бы на рынке труда в Австралии было бы много толковых разработчиков знающих Spring (MVC) 2.5 рарзрабатка enterprise applications была бы намного проще. Все таки learning curve для Spring Portfolio довольно приличный. Надеюсь, народ будет активнее подтягиваться к этому фантастическому фреймворку.

[Хирург]

Если бы на рынке труда в Австралии было бы много толковых разработчиков знающих Spring (MVC) 2.5 рарзрабатка enterprise applications была бы намного проще. Все таки learning curve для Spring Portfolio довольно приличный. Надеюсь, народ будет активнее подтягиваться к этому фантастическому фреймворку.

во-во, лубой прогресс должен упрошат веши, а не усложнят, а клучевое тут "Если бы на рынке труда в Австралии было бы много толковых разработчиков". Так как такого нет и не будет, надо мыслит категориями попроше, а не то придется "как ни крути, а морды лучше и быстрее делать на АСП.НЕТ" и вытягиват проект на ява, тогда как манагемент тянет на coldfusion, в case старой конторы, все новые проекты начинаются на coldfusion, а j2ee и все начиная c software development manager пошли лесом

Вообше факт, что ява девелоперы overarchitect things: давайте заинтродусим етот паттерн, а сверху 3 лайерс вот етого kода, с конфигурацией в ХМЛ в 5 разных местах, приправив усердно сверху фасадами, прокси обэктами, и прочими декораторами. А надо то всего пару страничек из базы вытянут и показат. Я часто с коллегами борюс, что надо чем проше, тем лучше, слава богу пока ПМ поддерживает, очен трезвый мужик.

[Romeo]

Вообше факт, что ява девелоперы overarchitect things: давайте заинтродусим етот паттерн, а сверху 3 лайерс вот етого kода, с конфигурацией в ХМЛ в 5 разных местах, приправив усердно сверху фасадами, прокси обэктами, и прочими декораторами. А надо то всего пару страничек из базы вытянут и показат. Я часто с коллегами борюс, что надо чем проше, тем лучше, слава богу пока ПМ поддерживает, очен трезвый мужик.

Да, полностью согласен, что с простыми проектами полегче в этом плане и много наворотов не надо. Мне вот посчастливилось работать над множеством complex enterprise applications с использованием open source technologies и таких методологий как Agile и Evolutionary Design. В таких проектах просто необходимо внедрять Application Layers и Domain Model. Иначе говоря использование Domain Driven Design. Обожаю работать над такими проектами, где OOA/OOD все еще ценится. Но персонально, даже для очень простых проектов люблю внедрять хотя бы Domain Model.
Хотя иногда Domain Model pattern может быть заменен на Table Module или Transaction Script (names coined by Martin Fowler) для очень простых проектов. В других же случаях (complex enterprise applications) Domain Model с эффективным Layering, OOA/OOD/OOP, AOP и помноженная на такие методики как Agile и Evolutionary Design - это гениальная и еденственно возможная (с точки зрения effective development, extensibility и maintainability) смесь!