Рамка на Google Guice за зависноста за инјектирање heise Developer

Истражување во 2.336.843 Производи

Google Earth и Maps се примери за иновативниот дух на гигантот во пребарувачот. Другите проекти се докажаа во развојот на Google. Млад член на ова семејство е рамка со отворен код Гице, чиста алтернатива на Спринг.

Google Guice, рамка со отворен извор за Dependency Injection (DI), беше создадена за време на проширувањето на апликацијата за рекламирање преку Интернет AdWords и имаше за цел да ги реши проблемите со скалирање на тимот што се јавуваат во проекти со неколку стотици развивачи. И покрај признатите рамки за DI како што е популарната пролет [1], Google сакаше да користи своја, особено лесна варијанта за внатрешен развој на софтвер (види „Лабава врска“).

Генериките и прибелешките од Java 5 се суштински дел од рамката [2]. Покрај тоа, Гице поддржува свои сопствени опсези (види го речник), аспект-ориентирано програмирање (AOP) и пролетна интеграција. Способноста да се инјектираат статички атрибути, како и управувањето со кружни референци, ја комплетираат сликата.

Планерот пристапува до специфичните часови HotelBooking и MockBooking преку интерфејс за резервација (Слика 1).

Пример за ова е апликација за планирање одмор што резервира хотели (Слика 1). Предметот планер (повикувач) се однесува на резервација на интерфејс, зад која се кријат специфични имплементации (целни објекти). За да не мора постојано да се пребарува реалниот целен систем за време на развојот, тука се користи т.н. потсмев предмет (атарот). Инвеститорот треба да може лесно да премине на продуктивно работење.

Рамката треба да изгледа особено слаба и масовно да го намали „кодот на котларницата“. Наместо да работи напорна работа, инвеститорот треба да се занимава со најважните работи. За таа цел, Гице се концентрира исклучиво на имплементација на DI со високи перформанси и соодветно е намален, како во однос на големината на JAR-датотеките, така и на потрошувачката на меморија. Гице не управува со зависностите во централните XML-датотеки, но ги зачувува во Java-кодот.

решаваат конфликти

Решавајте конфликти со Java

Искуството покажа дека развојот не се обемува ако премногу учесници се натпреваруваат за пристап до основните компоненти. Грдите конфликти се неизбежни кога работите со споделени XML-датотеки. Уредувањето на Java-датотеки е исто така полесно и помалку склоно кон грешки од уредувањето на големи XML-датотеки. Ова го прави рефакторирањето значително полесно и подобро поддржано од алатки. Гис веќе го помина практичниот тест во AdWords. Исто така е дел од добро познатата веб-рамка Struts 2, во која е централен елемент на архитектурата на приклучоци. Guice може да извршува корисни услуги во сите Java апликации. Големите проекти и оние што се фокусираат исклучиво на ефикасна корист од вбризгување на зависност, особено. Ова е местото каде што Гис може да ги покаже своите јаки страни како што се тенок и жици без XML (видете „Добро жичен“).

Апликацијата за планирање на годишни одмори повторно се користи како пример. Задачата на Гис е да му го додели на планерот посакуваниот специфичен објект за резервација, до кој може да пристапи преку интерфејсот. Во случајот што се разгледува, ова треба да биде објектот MockBooking. За да го направите ова, мора да се разјасни што каде се инјектира. На првиот дел од прашањето е одговорено таканаречен модул со „врзивно средство“, кој заедно го доделува интерфејсот на имплементацијата. Следната фрагмент од кодот формира таков модул и го користи методот bind () за да го поврзе интерфејсот за резервации со конкретната класа MockBooking .

Забелешката за „каде“ се грижи за коментарот за @Inject во планерот.

Забелешката @Inject означува дека објект за резервација треба да се инјектира со помош на конструкторот. Рамката го совладува инјекцијата на конструкторот (како во примерот), како и методот и инјекцијата на полето. Ова значи дека Гице исто така може да користи какви било анализирани методи или да ги инјектира директно во атрибут:

Инјекциските елементи се примитивни типови како што се int или char, како и enum и, воопшто, примери од која било класа.

Тест сценариото може да биде поедноставено со тоа што ќе се направи без модулот за планер со неговото врзување и со специфицирање на зададено обврзувачко поврзување во интерфејсот со помош на коментарот @ImplementedBy:

Откако инвеститорот ги моделира зависностите, Гис може да започне со работа. Разликува помеѓу иницијализација и траење. Кога апликацијата започнува, подигнувањето започнува со вбризгување на корен предмет. Гис се грижи за остатокот работејќи низ графикот за зависност и рекурзивно правејќи ги сите понатамошни инјекции. Се одвива валидација, што укажува на празнини или грешки. Користењето е едноставно како во овој пример:

Дел од секоја обврзувачка е снабдувач кој обезбедува примери од регистрираната класа. Во одредени случаи може да биде корисно или неизбежно да креирате предмети сами и да не го оставате ова на провајдерот за внатрешни стандарди. Ако користите библиотека од трети страни, не можете да внесете прибелешка @Inject таму, на пример. Со помош на кориснички провајдер сè уште е можно да се изврши обврзувачката. Давателите на услуги исто така овозможуваат интеграција со објекти испорачани преку JNDI или JMX.

Инјекторот како клучен елемент

Не плашете се од инјекции

Клучниот елемент во структурата на Гице е инјекторот, кој управува со врските (слика 2). Вторите користат прибелешка на целта на инјектирање и се однесуваат на тип што треба да се инјектира. Давателот создава примери од типот. Обемот на врзувањето е изборна спецификација и контролира повторна употреба на генерирани и инјектирани објекти. За секоја инјекција, Гис обично создава нова инстанца на предметниот предмет. Алтернативни опсези се „Синглтон“, „Барање“ и „Сесија“.

Покрај опишаните основни механизми, Гис знае низа дополнителни опции. Ова вклучува дефинирање на вашите сопствени прибелешки, кои, на пример, овозможуваат дополнително доделување на резервации за летови и изнајмување автомобили.

Кога ќе слушнете Инјекција на зависност или Инверзија на контролата, обично прво помислувате на Пролет. Не без добра причина, бидејќи тоа е фактички стандард кој зад себе има активна заедница. Како што веќе споменавме, и покрај своето постоење, Гугл гледа потреба за сопствено решение. Алтернативите како што се JBoss Seam, Apache HiveMind или Pico-Container не ја спречија компанијата да се развива внатре.

Двете рамки - Пролет и Гице - припаѓаат на производи со отворен извор и се под лиценцата на Апачи 2.0. Анотациите и генериките како компоненти на Guice дозволуваат употреба од Java 5. Ова не важи за Spring, може да се користи дури и со JDK 1.3 и нуди значително повеќе функции од Guice. Додека последниот се фокусира на ДИ, Пролет исто така поддржува трансакции, упорност и има своја веб-рамка. Подпроектите постојат за конфигурација, безбедност, серија работни места и уште неколку други.

Дефиницијата за зависности помеѓу објектите ја формира 'рбетот на рамката DI. Како се чуваат и проценуваат зависностите (жици на предметите) е карактеристична карактеристика. Ова покажува уште една голема разлика помеѓу Пролет и Гице. Пролетта овозможува експлицитно прикажување и автоматско ожичување. Гице има поинаков пристап: Иако се потпира на изречна претстава, тој го заобиколува разговорливиот XML формат со вклучување на односите во изворниот код со помош на Java прибелешки. Оваа постапка може да се сфати како мешавина помеѓу деталното, но интензивно одржување, експлицитното претставување и автоматското ожичување. Пролетта исто така дозволува создавање зависности во Java кодот со JavaConfig, но овој подпроект е сè уште во пресвртница.

изведба

Мал, брз, јасен

Guice ги покажува своите предности во однос на Spring како при започнување на апликацијата, така и за време на извршувањето кога станува збор за креирање на бараните објекти. Guice го постигнува водството кога креира објекти преку можности за истовремена Java 5. (Тоа треба да се промени со Пролет 3, кој ќе се базира целосно на Јава 5.) Покрај тоа, тој не генерира прокси-објекти што ги користи Спринг. Колку е ова релевантно во пракса, сепак зависи од природата на апликацијата.

Покрај техничките својства и опсегот на функции, аспектите како што е комплексноста се важни при изборот на алатка. Гугл гледа на Гис јасно во предност пред Спринг во однос на едноставноста, јасноста, одржливоста, ученоста и перформансите.

Генерално, бројните споредби на двата рамка генерираа возбуда во соодветните кругови. Како и да е, сепак, тоа не се сведува на одлука или, или, бидејќи иако и двајцата се DI контејнери, тие имаат различен фокус: Гис остава мал „стапало“, додека Пролет се нуди како сеопфатно и моќно решение. Голем дел од неговата комплексност XML, исто така, произлегува од функции надвор од DI. Бидејќи Гице не ги опфаќа овие области, нема вистинско ривалство. Соживотот на обете рамки е замислив, бидејќи Гис дозволува интеграција на зрното.

Планот за Гице 2 - планиран за јануари 2009 година - содржи голем број подобрувања, вклучувајќи слушател на конструкцијата и API за интроспекција. Слушателите нудат влезни точки при креирање на објекти за да ја закачат вашата логика. Проширувањето API е наменето да ги открие внатрешните делови на објектот Инјектор и да овозможи целосен пристап до графиконот за зависност. Ова ќе обезбеди почетна точка за алатките за визуелизација, на пример. Патоказот исто така ги именува методите на даватели со кои класите на модулите можат полесно да се дизајнираат. Така, давателите на услуги може да извршат пофлексибилно обврзувачко дејство што е ефективно само во одреден опсег, на пример.

Заклучок

Ниту блиц во тавата

Guice е сè уште нов, така што има малку продуктивни апликации надвор од Google. Гореспоменатата веб-рамка Struts2 е секако исклучок. Сепак, позадината на Google и употребата на AdWords ќе обезбедат дека Гице нема да заврши како блиц во садот. Модулите од трети страни кои сега постојат се дополнителен показател за ова. Ова вклучува компоненти што му овозможуваат на Гице да комуницира со Хибернат или рамката Ајакс DWR.

Во надолна линија, проектната документација е сè уште сосема јасна. Зголемениот број на извештаи за искуство и упатства донекаде го ублажуваат овој недостаток. Од архитектонска гледна точка, мора да се има предвид дека сопственичките прибелешки го отежнуваат повторното користење на часови во проекти што не се од Гвице. Гице е релативно лесно да се научи и да се воведе - дури и во постојните проекти. Друга предност е што рамката може да се инсталира чекор по чекор.

Тобијас Лутике
работи како архитект за решение во министерство во Велингтон, Нов Зеланд.

Кристијан Медер
е постар архитект во inovex GmbH во Пфорцхајм.

речник

Код на котлара: Повторлива, но потребна шема F-код што не ја отсликува деловната логика.

Инјектор: Компонента што исполнува зависност со инјектирање на посакуваниот предмет.

Модул: Контејнер за врзување што дефинира што треба да се инјектира.

Врзување: Врска помеѓу интерфејсот и неговата имплементација.

Опсег: Опсег на инјектиран предмет (на пр. Барање, сесија, единечен).

(Обичај) Давател: Создава предмети што треба да се инјектираат. Во варијантата „Прилагодено“ за индивидуално поврзување на компонентите што не се применуваат.

Bootstrapping: Иницијализација на Guice со вбризгување на коренскиот предмет со цел да се активира автоматското ожичување. Ова избегнува да мора повторно да го испрашувате инјекторот подоцна за секоја инјекција.

Анотации: Мета информации што инвеститорот ги зачувува во изворниот код на часовите Јава со претходниот знак „@“.

Генерики: Методи и класи што можат да се парамеризираат со параметрите на типот.

Добро жичен

Iringици го опишуваат начинот на кој рамката управува со зависностите помеѓу објектите. Постојат две основни форми: експлицитна застапеност во XML или Java и автоматско оценување според рамката за време на траење (автоматско ожичување). И двете варијанти може да се оценат. Во случај на автоматско ожичување, рамката се обидува да ги разбере односите помеѓу самите компоненти. Сепак, како што се зголемува комплексноста на апликацијата, ова создава проблем: перформансите стануваат сè полоши и полоши.

Лабава врска

Инјекцијата за зависност (DI) е популарен концепт во развојот на софтвер. Две од основните цели: да се поедностави повторната употреба и одржување на софтверот со лабаво спојување на компонентите и да се олесни тестирањето.

Кога објектот А има упатување на објект Б, тој обично знае за неговото спроведување. Концептот DI предвидува дека зависностите помеѓу повикувачот А и целите Б адресирани од него повеќе не се чуваат во А. Која имплементација на целниот објект Б треба да биде адресирана, се соопштува на повикувачот само кога е потребно. Односот со бетонот Б е "инјектиран" во А за оваа намена. Како повикувач, А не го знае целниот предмет што треба да се користи до последната инјекција.

DI е апликација на парадигмата Инверзија на контрола (IoC), позната и како Холивудски принцип: Не јавувај ни, ќе те повикаме. На овој начин, инјекцијата за зависност овозможува да се користат различни сценарија за употреба без да се прилагодува изворниот код на повикувачот за ова, на пример кога се додаваат нови имплементации на целните објекти. Чест пример за таква понатамошна цел е услугата како поедноставена варијанта на оригиналната услуга за тест цели. Ако на вистинската услуга и требаат многу ресурси и работи подолго време или воопшто е достапна само во продуктивната околина, имплементацијата како потсмев предмет (атарот) овозможува (побрзо) тестирање.