2 Vital:
авторОбъясните, пожалуйста, популярно, что мне даст использование технологии хивмайнд.
по аналогии со Spring, вы перестанете програмировать в Java и начнете програмировать в XML.

2 Vital:
авторЭто вы с сарказмом? ;)
Нет, это факт.

2 Vetal:
авторТо-есть, программировать в xml лучше чем в JAVA?
я думаю нет, поклонники Spring and etc. очевидно думают подругому

2 BlackWall:
авторЕсли я описываю бины в XML документе, это еще не значит что я перестаю писать на Джаве. К тому же, некоторые стандартные вещи таки приходится дописывать и расширять. Хотелось бы услышать обоснование, чем применение Spring может дать отрицательный результат. Конечно, если работодатель готов платить за изобретение все новых колес, то конечно, почему не сделать, например, RPC по-своему. Вот только покажите мне такого работодателя...
Почему я против Spring. Естественно все вещи в одном топике не уместишь да и нет желания тратить на это время, поэтому коротко о главном. Да, еще, не расценивайте этот топик как религиозное "Нет Spring!". Spring это фреймворк и весьма вероятно что в различных ситуациях его использование логично и оправдано, но...
1. Концепция IOC не нова и подразумевает, как и любой концепт, множество различных решений (Помимо Spring есть множество решений так или иначе решающих проблему IOC).
Имплементация подобных решений не обязательно означает изобретения колеса. А существующие решения основаные на классических design patterns и проверенные временем никому еще вреда не приносили. К примеру, для создания своего DAO вы преспокойно можете использовать решения описанные (включая UML, документация и примеры) на сайте SUN, IBM, etc в разделе 2ЕЕ. Естественно вам никто не запрещает использовать компоненты DAO сторонних разработчиков. Разница может быть, и как правило бывает, в том что при аналогичном уровне качества вам потребуется использовать гораздо меньше компонентов чем целый фреймворк.
2. IOS нужен только там где он действительно нужен. К примеру, у нас есть обьект BasicDataSource который мы хотим инициализировать в run time. Естественно, настройки для инициализации этого обьекта мы будем брать из properies файлов. Пользуясь Spring для решения этой задачи нам надо будет создать XML файл содержащий параметры для нашего ApplicationContextFactory или XMLContextFactory. Затем в этом файле мы опишем PropertyConfigurer и передадим ему наш properties файл в качестве источника. В нашем Java коде мы естественно инициализирыем ApplicationContextFactory или XMLContextFactory и затем инициализируем наш обьект BasicDataSource. Все просто и замечательно благодаря концепту IOC. Основная проблема может заключаться в том что для решения такой простейшей проблемы нам понадобиться включать в приложение целый фреймворк. Второй аспект в том что решение такой примитивной задачи требует у нас второго источника кода в виде XML файла. На первый взгляд появление XML файла не вызовет у нас беспокойства, разве что небольшое неудобство. Так ли это мы увидим дальше. На данный момент мы просто можем задать себе логичный вопрос, а можно ли решить эту проблему проще? Безусловно можно и притом гораздо легче (естественно о качестве решения мы не забываем, основываясь на проверенных временем примерах и design patterns). В любом случае мы идеально использовали IOC для решеня проблемы, хотя и заплатили за это лишними компонентами фреймворка и XML файлом.
Давайте теперь усложним задачу и примем во внимание что наша система будет использована на нескольких машинах и что на каждой машине наш properties файл будет иметь разные параметры. К примеры создаем приложение, пишем shell script который определяет машину (development, UAT или production) и передает соответствующий properties файл в виде системного аргумента в наше приложение. Использыя Spring мы выполним действия описанные выше за исключением того что нам нужно будет создать дополнительный обьект Resource который будет отображать содержимое нашего properties файла в run time основываясь на системном параметре (вспомните для чего мы писали shell script). Дополнительно нам понадобиться описать данный обьект в нашем XML файле. В любом случае, задача решена отлично, все работает правильно. Но за это мы заплатили лишним обьектом Resource и дополнительными записями в XML. Ну это еще не конец света конечно.
Давайте еще раз усложним задачу. Допустим наш properties файл должен хранить только праметры для работы с базой данных, а хранить пароли и логины мы будем в другом файле, общем для всех приложений. Таким образом у нас будет два properties файла. Возвращаемся к нашему проекту и повторяем предидущие действия. В этот раз однако нам понадобится второй обьект Resource с аналогичной функцией (отображать содержимое properties файла). Естественно мы продолжаем редактировать наш XML файл включая в него описание нового обьекта и поправляем PropertiesConfigurer чтобы он брал данные из нескольких файлов одновременно. Опять же все у нас работает замечательно. За исключением того что мы создали второй обьект необходимый для работы со Spring и увеличили содержимое XML файла.
Теперь давайте подумаем о том что будет с нашим XML файлом если мы будем продолжать описывать в нем конфигурации Spring? А ведь мы рассмотрели приметивнейший, хотя и реальный пример. Мы не работали с сылками на другие beans, мы не создавали sub beans и тд. И работали мы всего то с одним обьектом BasicDataSource.
Легко предположить каким станет наш XML фаил, или файлы, если мы будем продолжать в том же духе. Ирония состоит в том что мы для решения определенной проблемы должны искуственно создавать дополнительные трудности в виде дополнительных обьектов и XML ресурсов. Можно было бы решить первоначальную задачу проще? Безусловно, и ничуть не хуже.
3.Мы упоминали другие фреймворки и стандарты. Основной из этих стандартов EJB, которому Spring противопостовляется чаще всего. Один из аргументов Spring, в том что EJB достаточно сложен. Это может быть правдой, он безусловно не легок. Но и Spring требует знаний не намного меньших. Другой аргумент Spring в том что EJB привязывает ваше приложение к определенной технологии. Ну во первых Spring делает то же самое привязывая ваше приложение к Spring. А во вторых в привязывании приложения к EJB нет ничего негативного - EJB это определенная технология, поэтому вы используете данную технологию для решения каких то задач. При этом EJB, в отличие от Spring , это технология основаная на стандартах поддерживаемыми громадным количеством производителей и пользователей. К тому же в EJB 3 есть масса улучшений которые делают его использование проще и еффективнее. Ну и последне, над EJB в отличие от Spring работают гораздо больше и тшательнее, что согласитесь один из важнейших факторов.
4. Общий концепт Spring подразумевает специфические знания которые могут быть применены в очень ограниченном числе фреимворков. Отсюда вопрос, зачем требовать от разработчиков узких и очень специфических знаний вместо того чтобы поощрать развитие уже имеющихся общепринятых навыков? Есть точка зрения что Spring стимулирует использование design patterns. Это не неверно. Если разработчик не хочет или не может пользоваться design patterns, никакой Spring не заставит его никто это делать. Не лучше ли стимулировать таких разработчиков к использованию очевидных и фундаментальных вещей вместо того чтобы толкать их к использованию субьективных подходов? Есть мнение что Spring прост в использовании. Это не совсем так. Как и любая вещь он требует знаний и опыта. Я видел кучу примеров когда люди используют Spring всего лишь для инициализации POJO обьектов. Выглядит эта мотня из XML фаилов ужасно. На вопрос аргументировать использования POJO в ответ обычно выглядит так: ну это же IOC. Да, ну и что дальше? Ну Spring же контейнер. Да, ну и что дальше? Ну мы же можем конфигурировать IOC. Да, ну и что дальше? То есть люди не особо понимают смысл определенных вещей. И от этих ошибок в итоге страдают их коллеги и весь проект.
5.Этот пункт в принципе продолжение предыдущего. Дело в том что использование Spring может породить кучу проблем с поддержкой приложения. Скажем, ваше приложение исользует Spring очень интенсивно. Со временем разработчики покидают вашу команду и приходят новые люди. Так вот, даже если у вас содержится полная документация вашего приложения (а это очень большое если во многих случаях к сожалению) вашему разработчику понадобится потратить время на изучение самого Spring . Хотите найти тех кто уже хорошо знает Spring? Ну флаг вам в руки и электричка на встречу :) Гораздо легче найти хорошего специалиста в EJB чем хорошего в Spring.

В общем это мое мнение, ни в коем случае никому не навязываемое. Это просто мой опыт и мои наблюдения. Наверняка я упустил кучу вещей (AOP and etc) о которых думал паралельно с написанием топика. Если появятся мысли постараюсь их выложить.

2 funikovyuri:
авторВо-первых Spring != IoC, IoC это только часть библиотеки (хотя и центральная). Так что говорить, что есть другие реализации IoC я думаю не стоит, так как на сегодня только в Spring реализован общий подход на основе IoC/AOP/DAO etc.
а где вы видели что я ставил знак равенства между S и IOC? Как вы сказали IOC является одним из основных концептов S и именно по этому поводу я его и упомянул. Естественно мои замечания относятся к тому как S реализует IOC, а не к IOC самому по себе.

Да S предоставляет дополнительные возможности по сравнению с аналогичными фреймворками. Наверняка какие то решения в S реализованы лучше а какие то хуже чем где то. Тем не менее это не делает S чем то особенным или суперполезным. Во всяком случае не всегда.

авторВо-вторых, мне кажется, что вы не до конца понимаете назначение библиотеки. Там как раз основной целью было облегчение тестирования и сопровождения. А основным лозунгом, что одно из самых ценных качеств ООП - это возможность объекта быть заменяемым. При этом этих целей они добились на 100% - а вы пишите наоборот.
Какое из моих высказываней натолкнуло вас на эту мысль? Да S добился этой цели на 100% как вы сказали. Я это как раз таки подтверждал по ходу приведенного примера. Мой аргумент состоит в том что S требует дополнительных ресурсов в виде лишних обьектов и xml файлов.
авторТакже вы пишите что Spring привязывает приложении к технологии. Это не так - он как раз ничего (точнее его IoC часть) не привязывает, а как раз наоборот. Весь Spring-specific код - это код xml-файла. Сами же объекты полностью лишены каких-либо зависимостей от Spring. Imho это не сравнимо с EJB2 где зависимость огромна. Да кстати, тот же EJB3 тоже перешел на IoC.
Опять же речь не идет об IOC а как раз о том как S реализует этот концепт. ИМХО избыточное использование xml и разнос кода (особенно без необходимости) только усложняет работу с проэктом. Вы с этим не согласны?
авторинтересно как? захардкодить? да уж ни чем не хуже. Мне лично не ясно, почему имея 2 файла (2 ресурса) вы стараетесь скрыть это в коде приложения. Их два есть и два будет в Spring'е - так что тут не так?
почему бы и нет? Чем плоха хорошая реализация в java по сравнению с хорошей реализацией в xml?
авторPS> Вообще мое мнение на счет Spring'а - это на редкость полезный и верный продукт - один из лучших framework'ов для java. А Rod Johnson, один из толковейших архитекторов, который смог придумать и реализовать действительно новую и полезную идею
Возможно вы правы, но пока что я остаюсь при своем мнении. Да S не плохой продукт, да он решает определенные задачи. Но я не считаю что он имеет свои недостатки как и любой другой продукт. С госодином Rod Johnson я кстати встречался несколько раз, хотите от вас пламенный привет передам :)?