Google Guice

Зачастую, использование спринга не обязательно и только мешает, а тут еще их и плодить начинают.

надо попробовать, ибо спринг тормозной до ужаса..

Dependency Injection - это "впрыскивание" зваисимостей

Как-будто промтом переводили =)

> использование спринга не обязательно и только мешает

Это точно. Есть новые EJB (хоть с TopLink, хоть с Hibernate, хоть с JDO, например, Kodo) и JSF. А остальное - мы "бритвочкой Оккама".

Поделия типа Spring, Velocity, Struts, Tapastry и прочие - в биореактор.

s/Tapastry/Tapestry ("Вышивка")

>Поделия типа Spring, Velocity, Struts, Tapastry и прочие - в биореактор.

Было бы интересно знать чем вам Tapestry не угодил? Tapestry по сути тот же JSF, только появился гораздо раньше.

Про новый EJB - те же яйцы, Hibernate это конечно круто и Seam мне понравился, но вот когда я на этом production решения буду писать/сопровождать - я ваще хз. А спринг - вот он родной, сидит и есть не просит.

Про тех товарищей, которые говорят, что спринг тормозной - в топу дибилы.

>Про новый EJB - те же яйцы, Hibernate это конечно круто и Seam мне понравился, но вот когда я на этом production решения буду писать/сопровождать - я ваще хз. А спринг - вот он родной, сидит и есть не просит.

по поводу продакшна, пишут, что: "We've been running Guice in mission critical applications for months, and now you can, too."

Guice не Spring, потому как Guice это IOC, а Spring пытается быть универсальным решением всех ваших проблем создавая при этом новые. А ещё весь этот XML... Кошмар вообщем! А вот Guice это то что я лично ждал и надеялся что подобное напишут. Смотрел в сторону Tapestry 5 IOC, но разочаровался - слишком сложно и закручено, а также присутствуют "магические" префиксы в именах методов (для сервиса "CoolSvc" метод который его построит будет называтся "buildCoolSvc").
Guice довольно прост и не смотря на версию "1.0" функциональность достаточна для типичных проектов над которыми я работаю. Рекомендую всем Java разработчикам хотябы прочитать "User Guide" (пол часа хватит) а потом уж говорить о биореакторе.

Пример то с counter удалось собрать и задеплоить?

>Guice не Spring, потому как Guice это IOC, а Spring пытается быть универсальным решением всех ваших проблем создавая при этом новые.

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

>А ещё весь этот XML... Кошмар вообщем!

хмл конечно не сахар ( более того по моему мнению - конкретный геморрррр), однако в данном случае он обладает некоторыми неоспоримыми преимуществами

1) при внесении изменений в конфиг не нужна компиляция.

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

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

Так в основных фреймворках (если я не ошибаюсь) аннотации можно "перебивать" настройками из xml.

>- Guice генерирует понятные отчёты об ошибках, если бы их читал человек.

А поскольку их читает не человек, он их не генерирует.

>Так в основных фреймворках (если я не ошибаюсь) аннотации можно "перебивать" настройками из xml.

Да, можно.

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

Вообще-то, если это возможно, я избегаю использования Спринга. Есть NanoContainer, PicoContainer, например. А опыта у меня может и поболее Вашего :)

> 1) при внесении изменений в конфиг не нужна компиляция.

Не понимаю, почему некоторые разработчики так боятся компиляции?

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

Ничего нигде конфликтовать не будет априори. Почитай "Annotation Processing", а ещё лучше напиши свои обработчики анотаций и тогда будет намного яснее

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

А вот для меня совсем наоборот. Когда есть аннотация, я сразу вижу каким образом метод/свойство используются. Мало того: 1. Можно сразу прочитать JavaDoc и ещё лучше разобратся в деталях 2. Аннотации описываются одинаково и я могу прямо в IDE прочитать документацию потому как аннотация это в принципе класс. А вот каждый фреймворк который использует свой формат XML в котором ещё нужно долго разбиратся и не всякая IDE поддерживает тот или иной фреймворк. И будет за счастье если разработчики фреймворка документировали схему для своего формата XML. Чаще же, XML формат даже не описан схемой! А это гемор похлеще любой перекомпиляции 3. Рефакторинг аннотированого класса значительно проще.

Однако я вовсе не говорю что XML это зло. Я считаю что всему своё место, также как каждому своё. Лично для меня, IoC(ORM) работающий с аннотациями намного более приемлем чем IoC(ORM) работающий с XML.

когда текст переводят дилетанты, получается каша-малаша из слов :) Особенно смешно "инверсия зависимостей" :)

--седайко стюмчик

Очень русского языка обожаю и люблю. (с) Александр Иванов.

s/В кратце:/Вкратце/

> - Guice берёт заботу над сильной комплексацией кода.

"берёт на себя заботу о сильной комплексации кода". заботу нельзя брать над чем-то.

> - Guice уменьшает излишний код.

какой смысл _уменьшать_ излишний код? излишний код нужно убирать. слово "излишний" явно излишнее :)

> - Guice, где уместно использует внешние настройки.

самолет, когда удобно летать на нем. машина, чем я езжу в работу. это на каком языке?

> - Guice генерирует понятные отчёты об ошибках, если бы их читал человек.

"генерирует отчеты об ошибках, понятные для человеческого восприятия" или что-то вроде этого.

Ребята, а Вы вообще читаете то, что пишете?

Вообще-то "включение", "вложение".

В математике функция F:X->Y называется инъекцией (или вложением, или отображением в Y), если разные элементы множества X переводятся в разные элементы множества Y. :) (шучу)

Попробовал. Понравилось. Пример заработал, но build.xml под Ant свой любимый (консерватор я) слегка "напильничком" поправил.

>Есть NanoContainer, PicoContainer, например.

+1

это и используем, ибо просто и быстро. а сприг, различные RPC нет.

> - Guice берёт заботу над сильной комплексацией кода.

код потом сильно комплексует? В тим обязательно нужно брать психоаналитика?

> - Guice позволяет делать простые и быстрые тесты на всех уровнях.

изготовлен специально для пипискомерения чтоли?

> - Guice уменьшает излишний код.

я подозреваю за счёт увеличения неизлишнего. Закон сохранения кода никто не отменял. Его даже открыть не успели впрочем.

> - Guice является типизированным (type safe).

"типа сейф". Аха, непробиваемый. Видали таких. Угадайте, где.

> - Guice, где уместно использует внешние настройки.

regedit прилагается?

> - Guice позволяет собрать приложение из компонент, которые действительно независимы.

Имеют склонность вылетать на йух с криками "швабода, швабода!"

- Guice генерирует понятные отчёты об ошибках, если бы их читал человек.

Верно подмечено. Ах, если бы человек читал отчёты об ошибках...

> - Guice маленький и очень быстрый.

чтобы не поймали, не убили? Значит есть за что?

>Ребята, а Вы вообще читаете то, что пишете?

При обращении к множеству людей, пишется "вы" (с маленькой буквы) ... ;-) Но фанатизмом тоже наверное не надо страдать, т.к. иногда просто не замечаешь очередную оЧепЯтку, либо используешь сленг, игру слов, или используюешь имена систем как нарицательные (в примере, "Guice (Вася), где уместно, использует внешние настройки" . Я это пишу не в защиту безграмотности, а просто что форум и официальный документ это всё-таки разные вещи.

Вот только что сам написал это, и заметил отсутствие множества запятых... Нужно над собой работать ;-)

Есть предложение. Выдать этому сообщению приз как самому безграмотному (недели? месяца? года?). Особо отметить "Dependency Injection (инверсия зависимостей)" (долго думал), "сильную комплексацию" (ржал полчаса), "В кратце" (потерял веру в человечество).

Повторяем дискуссию нс TSS, но теперь на русском языке :) ?
Поклонники Hivemind на ЛОРе найдутся?

> Вот только что сам написал это, и заметил отсутствие множества
> запятых... Нужно над собой работать ;-)

Зачем? Просто довертесь виртуальной машине (с) :)

>Зачем? Просто довертесь виртуальной машине (с) :)

Нее... тут наоборот! Нужно везде расставить запятые, и ждать виртуальную машину ;-)

По ссылкам ходить, как всегда, не модно? Не запятые, а "собаки" надо расставлять!

>Не запятые, а "собаки" надо расставлять!

Да жалко как-то, собачек-то... Пусть пока живут, а? 8-)

Вы с кем спорите? Вы с гуглом спорите?!

По теме - граждане модераторы, кроме шуток, почистите новость. Или удалите нафиг. Позорище же.

разве ты сам немодератор?

Нет

а был вроде?

Никогда не был

>Никогда не был

Так стань им! Мне показалось или у тебя 3 часа назад были только 3 звезды ;)

Обязательно. Про звезды - глюк. У меня уже давно 4.

>В кратце:

ого! сильно комплексационно все как-то.

tight coupling - высокая связность - то бишь guice уменьшает связность

boilerplate code - тупой/шаблонный код - то бишь избавляет от тупого кода

а ценители русского тут и без меня поругаются:)

>Было бы интересно знать чем вам Tapestry не угодил?

О глючности и кривости этого поделия можно рассказывать часами.

>Не понимаю, почему некоторые разработчики так боятся компиляции?

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

>Ничего нигде конфликтовать не будет априори

Кроме того, что inversion of control это подконцепция более общей концепции cross-cutting concerns, и предназначена для уменьшения связности, а точнее разнесения различных аспектов в разные части с целью локализации изменений. Запихивая тучу аннотаций из разных аспектов в одно и то же место заставляет задуматься, а в чем тогда фишка? Тем что связность организуется не посредством склассов, а посредством аннотаций? Дык 'нет никакой разницы'. Если бы еще аннотации были в самом общем виде - например описывали как объект нужно персистить и восстанавливать безотносительно конкретного механизма - в этом был бы смысл. А если что не фреймворк, то хочет напихать своих аннотаций куда попало - так это махровый бред.

>Когда есть аннотация, я сразу вижу каким образом метод/свойство используются.

Это и называется "tight coupling", а ты думал это какие-то звери абстрактные? Если возле твоего метода написано, как оно должно использоваться, значит abstractness такого кода ниже плинтуса, там же его reusability и прочие умные слова, которые в кругах больших эстетов принято называть метриками.

>3. Рефакторинг аннотированого класса значительно проще.

Ох как часто я слышал такую отмазу по любому поводу. Сначала испоганить код высокой связностью, чтобы его было проще рефакторить. Вдохни свежий воздух, подумай еще раз, почитай что-то на тему variability, abstractness, и прочих окологенеративных слов.

>Лично для меня, IoC(ORM) работающий с аннотациями намного более приемлем чем IoC(ORM) работающий с XML.

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

r - респект...

по поводу hivemind.

замечательный фреймворк, много фич... но есть пара косяков, которые для меня лично hivemind похоронили и самый главный косяк - ужасный xml у которого _принципиально_ нет схемы (типа чтоб проще было свои вставки делать) соотвественно редактировать его нереально (особенно если делаешь это нечасто и более того, каждый компонент имеет свою "подсхему" которая тоже "описана" только в hivedoc). После 3 месяцев этого ужаса - spring xml - счастие безмерное.... особенно 2.0

+1

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

ORM - это понятие, и путать/уравнивать его с реализацией (аля Hibernate) некорректно. Любой ООП проект использует ORM (либо руками, либо через всякие frameworks).

> Есть предложение. Выдать этому сообщению приз как самому безграмотному (недели? месяца? года?). Особо отметить "Dependency Injection (инверсия зависимостей)" (долго думал), "сильную комплексацию" (ржал полчаса), "В кратце" (потерял веру в человечество).

А также выдать приз пользователю svu - за идею выдачи приза сообщению.

> ужасный xml у которого _принципиально_ нет схемы ...
Да, я сначала тоже так думал, а потом как-то прикинул такую вещь:
В spring'е бин конфигурируется посредством xml, который укладывается
в схему, но эта самая схема никак не проверяет правильность самих
передаваемых значений. То есть, можно написать правильный xml (именно
как xml), но при этом кривой с точки зрения самого фреймворка. То
есть, схема принципиально, лишь упрощает написание, но не гарантирует полную правильность. С другой стороны, та самая принципиальная
невозможность иметь эту самую схему, связана именно с конфигурациями, а те в свою очередь модут расспологаться в любом пакете. Таким
образом можно вынести конфиги в отдельные пакеты (файлы), а для всего
осталного пользовать схему. Тогда можно даже и для конфигов схемы понаписать :). По идее должно пройти - я по крайней мере, конфиги
держал в отдельных файлах. Правда схем для всех этих радостей я не писал, но было бы интересно узнать, может кто такую идею и применил.
Кстати, hivemind-2 alpha вышел - наобещали много вкусного, ждёмс :)

> Любой ООП проект использует ORM (либо руками, либо через всякие frameworks).

При чем тут ООП? Из ООПшности проекта не проистекает, что есть необходимость все превращать объектные концепты языка реализации. Например, если весь смысл в реализации некоторого просмотрщика/редактора для данных находящихся в некотором хранилище - превращать их в объекты совсем не надо. Можно например описать схему данных, в которой будет описана типизация и правила валидации, и использовать обобщенный подход к редактору, просмотру и персистенсу этих данных. Нету необходимости превращать данные хранящиеся в базе в объект, чтобы потом превратить его в маркап, и обратно - это лишняя фаза.

Прочитал комментарии к новости, и выложил переработанный текст:

--->8-----------------

Google объявила о выпуске своего легковесного программного комплекса для Java 5 - Guice (произносится как 'juice'), который работает по принципу шаблона Dependency Injection (инъекция зависимостей) и доступна под лицензией Apache License 2.0. Guice полностью использует мощь Java 5 и повсеместно использует аннотации и параметризуемые классы (generics).

Вкратце:

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

--->8----------------

P.S. Спасибо за комментарии, в частности r и Ingwar.
P.P.S. По поводу перевода, спешил и переводил быстро, к тому же сказывается неточность/разнообразие терминов/заменителей на русском языке. Изучаю сие технологии на английском и на нём же читаю книги. К тому же, образование (ср. и выс.) я получал на английском языке и все предметы мы также изучали на английском (даже периодическая таблица элементов была другая - не Менделеевская :)). Зачастую, в русском языке нет адекватных и точных заменителей терминов и переводов, например, таких слов, как framework, engine, и др.

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

Конкретный пример можешь привести?

Требую от Гугля линуксовый Google Talk хотя бы в таком виде, как Earth. Пока не будет, мне с ним не о чём разговаривать!

> Нету необходимости превращать данные хранящиеся в базе в объект, чтобы потом превратить его в маркап, и обратно - это лишняя фаза.

Все примеры (которые я видел), где народ напрямую запихивал данные из базы в маркап - были проектами уровня "редкостный бардак" или уровня "hello world".

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

Ассоциация имхо некорректная. В принципе можно принять что компилятор это редактор "class"-файла а интерфейсом к нему есть код на Java, тогда редактирование текстового файла = компилирование.

> Кроме того, что inversion of control это подконцепция более общей концепции cross-cutting concerns, и предназначена для уменьшения связности, а точнее разнесения различных аспектов в разные части с целью локализации изменений. Запихивая тучу аннотаций из разных аспектов в одно и то же место заставляет задуматься, а в чем тогда фишка? Тем что связность организуется не посредством склассов, а посредством аннотаций? Дык 'нет никакой разницы'. Если бы еще аннотации были в самом общем виде - например описывали как объект нужно персистить и восстанавливать безотносительно конкретного механизма - в этом был бы смысл. А если что не фреймворк, то хочет напихать своих аннотаций куда попало - так это махровый бред.

Пример:

public class ServiceImpl implements Service {
@Inject
public ServiceImpl(MyDAO dao) {
}

public Object do(...){...}
}

Это не туча аннотаций, а всего одна и говорит что всё параметры для конструктора должны быть "вставлены". И разница есть: без IOC нужно было бы написать фабрику для этого сервиса, а так не нужно.

> Это и называется "tight coupling", а ты думал это какие-то звери абстрактные? Если возле твоего метода написано, как оно должно использоваться, значит abstractness такого кода ниже плинтуса, там же его reusability и прочие умные слова, которые в кругах больших эстетов принято называть метриками.

Смотри предыдущий пример. И где тут "tight coupling"? Ничто не мешает мне использовать этот код без использования Guice.

> Ох как часто я слышал такую отмазу по любому поводу. Сначала испоганить код высокой связностью, чтобы его было проще рефакторить. Вдохни свежий воздух, подумай еще раз, почитай что-то на тему variability, abstractness, и прочих окологенеративных слов.

Допустим ты убираеш свойство из объекта. Если свойство было аннотировано то ты автоматически удаляеш и аннотации. Если же используется внешний XML для описания чего либо что использует это свойство то ты в полной заднице. А про связанность я уже упоминал в предыдущем параграфе.

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

Я же чётко сказал "Я считаю что всему своё место, также как каждому своё". Так что в каждом конкретном месте - оптимальный подход. Поэтому не стоит считать что всё проекты это "проект, в котором этот самый ORM персистится более чем в одном источнике..." поэтому не стоит всех косить под свою гребёнку.