Как вы уже догадались из названия, разговор у нас сегодня пойдет о легковесных контейнерах.

Началась все с того, что я вот задумался, откуда у мекня столь стойкое неприятия Спринга, при том что я в свое время прочел книжку Рода Джонсона "J2EE Development without EJB" от корки до корки и всем сердцем принял излагаемые там идеи. С этим вопросом за пазухой полез я в инет и... практически не нашел сколько-нибудь серьезной критики Спринга. Но кое-что все-таки нарылось. Например вот это: I Don't Get Spring
 за авторством чувака из Гугла по имени Bob Lee.

И в общем-то то что там написано действительно хорошо описывает мои собственные ощущения:

• обилие XML кодирования
• тяжеловесность во всем (вопреки заявленному)
• плохая поддержка дженериков и аннотаций.

При этом отмечается, что есть у Спринга безусловно и очень сильные достоинства: декларативные транзакции, подтыкаемые имплементации многих сервисов, гибкий халявный ремоутинг и пр.

Ну и тут же у меня возник закономерный вопрос: ну дак а что взамен Спринга-то? Что заюзать бедному девелоперу?

И оказалось вот что: Легкий фреймворк под названием Guice (произносится Juice) разработанный для внутреннего пользования Гуглом и не так давно открытый для широкой публики как опенсорс

Полистал я доку, ознакомился. И знаете что скажу: а ведь это, братцы, прорыв. Может быть совсем скоро мне лично не придется изобретать велосипед, потому что все основные нужные мне вещи будут доступны в базовой поставке Guice.

Вот такие вот новости с полей. Прошу высказываться.

ЗЫ. Поиском на форуме нашел одно упоминание Guice от alexsmirnov, но это было сделано всколзь и с акцентом на другую интересную разработку, Web Beans. В общем, тема новая и актуальная

Как бы ни превозносились все эти "легковесные" фреймворки, легковесность их проистекает из новизны и бедности. Когда функционал дорастает до приемлемого, легковесность куда-то исчезает ;) Никогда не воспринимал серьёзно вариаций на тему "JEE без EJB".

w1nd, EJB3 уже сами по себе "легковесные" в сравнении с EJB2

Если простоту в использовании (мнимую, кстати) назвать легковесностью - то да 

Это сообщение отредактировал(а) w1nd - 4.6.2008, 00:08

Stampede
О каком сабсете функциональности Spring'а идет речь? В смысле, что конкретно хотим заменить?

Maksym, подозреваю, что в части Dependency Injection

Во, спасибо за подсказку. А то я было даже как-то растерялся 

В общем, хочется, "чтобы у меня все было, и мне за это ничего не было" (с). В смысле, чтоб не приходилось программить в XML - ну не  для того он предназначен. В Guice это достигается широким использованием аннотаций. Правда, некоторые вменяют это фреймворку в вину: мол, какое же это DI и  IoC, если мы должны явно показывать пальцем, где чего фтыкать - само должно разруливать. Кроме того, говорят они, повсеместно раскиданные анотации делают код сильно зависимым от фреймвокра - нехорошо, инвазивно.

Но позвольте, а чего же вы хотели, граждане? Где-то, как-то, но зависимости все равно нужно каким-то образом описать. Не хотите в аннотациях - флаг... то есть, простите, XML вам в руки. Только погодите: где-то мы такое уже видели - уж не в Спринге ли: раздутые конфиги, плохая тестабельность, кошмары рефакторинга...

То есть если мы согласимся, что в вопросе выбора между аннотациями и конфигами аннотации выигрывают (особенно так как это сделано в Guice: типобезопасно и удобно), то останется, по сути, лишь одно возражение: кастомные аннотации.

Так вот, кастомные они лишь до тех пор, пока их не канонизировали. А принимая во внимание тенденции в JCP (скажем, стандартизацию ОРМ в форме JPA, или скриптинга на базе Rhino), за этим дело не заржавеет. Потому что уж больно безобразная складывается ситуация с IoC контейнерами: продуктов все прибавляется, а порядка не видать. Так вот осмелюсь предположить, что путь, который выбрали авторы Guice - он гораздо прямее ведет к канонизации чем путь Спринга, который давно уже перестал быть просто контейнером, и включать в SE такого монстра в мало-мальски самодостаточном объеме ни у кого рука не поднимется.

Плюс не забываем, что за Guice стоит ни много ни мало сам Гуголь - даже если не деньгами, то фигурой.

Так штааа...

я как-то видел реплику на rsdn , мол , когда у меня в проекте больше 2 классов, всегда использую Спринг, а то легко запутаться с порядком инициализации    

Stampede, вопрос такой, а как у guice обстоят дела со вторым китомспринга - АОП? На мой взгляд именно аспекты, позвояющие с легкостью реализовывать фукционал ортогональный основному (такой как, например, секьюрити и транзакционность),  позвоили спрингу претендовать на место EJB.
Кстати по поводу аннотаций в спринге http://weblogs.java.net/blog/seemarich/arc...ion_base_1.html
За подробностями - в спринговый референс. Конечно какой-то минимальный хмл остается, но перспектива кодить giuce'овский биндер мне пока кажется не менее сомнительной. Хотя может я еще не распробовал.

Это сообщение отредактировал(а) fixxer - 4.6.2008, 20:21

Ваще-то почти все эти беды - это не ограничения спринга, это "общепринятые" способы его использования. если вам не нравятся хмл конфиги (мне не нравятся) никто не запрещает производить конфигурацию контекста программным образом, получая полную поддержку рефакторинга.

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

лучшее API - это остутствие API, лучший контейнер - тот, которого не заметно.

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

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

Это сообщение отредактировал(а) xeye - 5.6.2008, 00:51

Если бы у бабушки были яйца, то она была бы дедушкой. API есть всегда и вопрос только в том, насколько хорошо оно спроектировано.


В принципе согласен - можно. Только насколько это нужно и удобно - вопрос открыт. 
В конце концов та же идея SPI (Serevice Provider Interface) на котором строится очень немалая часть технологий Java - наглядный пример того, что Guice может реально помочь разработчикам.

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

ну, поверьте на слово, это удобно 

забавно, что spring MVC не использует в полной мере возможности спринга, как IoC. т.е. это не проблема спринга, это чисто проблема использования. проблема в том, что сами авторы не смогли подать красивый и внятный пример мощного использования IoC. в итоге имеем систему быстро нагоняющую EJB по монстричности.

пример web MVC на основе пикоконтейнера :  http://waffle.codehaus.org/

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