Google Guice Framework за Injection Dependency heise Developer

Изследвания в 2,336,843 Продукти

Google Earth и Maps са примери за иновативния дух на гиганта на търсачките. Други проекти са се доказали във вътрешното развитие на Google. Млад член на това семейство е рамката с отворен код Guice, постна алтернатива на Spring.

Google Guice, рамка с отворен код за Dependency Injection (DI), е създадена по време на разширяването на приложението за рекламиране в Интернет AdWords и е предназначена да реши проблеми с мащабирането на екипа, които се появяват в проекти с няколкостотин разработчици. Въпреки признатите DI рамки като популярната Spring [1], Google искаше да използва свой собствен, особено лек вариант за вътрешно разработване на софтуер (вж. „Свободни отношения“).

Общите и анотациите от Java 5 са съществена част от рамката [2]. В допълнение, Guice поддържа свои собствени области (вижте речника), ориентирано към аспекти програмиране (AOP) и пролетна интеграция. Възможността за инжектиране на статични атрибути, както и управлението на циркулярни референции допълват картината.

Планиращият достъп до специфичните класове HotelBooking и MockBooking чрез интерфейс за резервация (фиг. 1).

Пример за това е приложение за планиране на ваканция, което резервира хотели (Фигура 1). Обектът на планиращия (повикващия) адресира интерфейсна резервация, зад която са скрити конкретни изпълнения (целеви обекти). За да не се налага непрекъснато да разпитвате реалната целева система по време на разработката, тук се използва така наречения фиктивен обект (манекен). Разработчикът трябва да може лесно да премине към продуктивна работа.

Рамката трябва да изглежда особено постна и значително да намали "кода на шаблона". Вместо да работи усилено, разработчикът трябва да се справи с най-важното. За тази цел Guice се концентрира изключително върху високоефективно изпълнение на DI и съответно е намалено, както по отношение на размера на JAR файловете, така и по отношение на консумацията на памет. Guice не управлява зависимостите в централните XML файлове, но ги съхранява в Java кода.

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

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

Опитът показва, че развитието не се мащабира, ако твърде много участници се състезават за достъп до основните компоненти. Грозните конфликти са неизбежни при работа със споделени XML файлове. Редактирането на Java файлове също е по-лесно и по-малко податливо на грешки, отколкото редактирането на големи XML файлове. Това прави рефакторинга забележимо по-лесен и по-добре подкрепен от инструменти. Guice вече е преминал практическия тест в AdWords. Също така е част от добре познатата уеб рамка Struts 2, в която е централният елемент на архитектурата на приставките. Guice може да изпълнява полезни услуги във всички Java приложения. Големите проекти и тези, които се фокусират изключително върху ефективната инжекция на зависимост, се възползват по-специално. Тук Guice може да покаже своите силни страни като тънкост и без XML окабеляване (вж. „Добре окабелени“).

За пример отново се използва приложението за планиране на ваканция. Задачата на Guice е да присвои желания конкретен обект на резервация на организатора, до който той може да осъществи достъп чрез интерфейса. В разглеждания случай това трябва да е обектът MockBooking. За целта трябва да се изясни какво къде се инжектира. На първата част от въпроса се отговаря от така наречения модул със „свързващо вещество“, който заедно присвоява интерфейса на изпълнението. Следният кодов фрагмент формира такъв модул и използва метода bind (), за да обвърже интерфейса на Booking с конкретния клас MockBooking .

Анотация @Inject в обекта на плановика се грижи за "къде":

Анотацията @Inject показва, че обект на Booking трябва да се инжектира с помощта на конструктора. Рамката овладява инжектирането на конструктор (както в примера), както и инжектирането на метод и поле. Това означава, че Guice може също да използва коментирани методи или да ги инжектира директно в атрибут:

Инжекционните елементи са примитивни типове като int или char, както и изброявания и като цяло екземпляри от всеки клас.

Тестовият сценарий може да бъде допълнително опростен, като се направи без модула за планиране с неговото обвързване и задаване на обвързване по подразбиране в интерфейса с помощта на анотацията @ImplementedBy:

След като разработчикът моделира зависимостите, Guice може да започне да работи. Той прави разлика между инициализация и време на изпълнение. Когато приложението стартира, стартирането започва с инжектиране на корен обект. Guice се грижи за останалото, като си проправя път през графиката на зависимостите и рекурсивно прави всички следващи инжекции. Провежда се валидиране, което показва пропуски или грешки. Използването му е толкова просто, колкото в този пример:

Част от всяко обвързване е доставчик, който предоставя копия на регистрирания клас. В определени случаи може да бъде полезно или неизбежно да създавате сами обекти и да не оставяте това на доставчика на вътрешния стандарт. Ако използвате библиотека на трета страна, например не можете да въведете анотация @Inject. С помощта на персонализиран доставчик все още е възможно да се извърши обвързването. Персонализираните доставчици също позволяват интеграция с обекти, доставени чрез JNDI или JMX.

Инжекторът като ключов елемент

Не се страхувайте от инжекции

Ключовият елемент в структурата на Guice е инжекторът, който управлява връзките (Фигура 2). Последните използват анотация върху инжекционната цел и се отнасят до тип, който трябва да се инжектира. Доставчикът създава екземплярите от типа. Обхватът на обвързването е незадължителна спецификация и контролира повторното използване на генерирани и инжектирани обекти. За всяко инжектиране Guice обикновено създава нов екземпляр на въпросния обект. Алтернативни обхвати са "Singleton", "Request" и "Session".

В допълнение към описаните основни механизми, Guice познава редица допълнителни опции. Това включва дефиницията на вашите собствени пояснения, които например позволяват допълнително задаване на резервации за полети и коли под наем.

Когато чуете Инжектиране на зависимост или Инверсия на контрол, обикновено първо мислите за пролетта. Не без основателна причина, тъй като де факто стандартът има активна общност зад себе си. Както вече споменахме, въпреки съществуването си, Google вижда нужда от свое решение. Алтернативи като JBoss Seam, Apache HiveMind или Pico-Container не попречиха на компанията да разработи вътрешно.

И двете рамки - Spring и Guice - принадлежат към продуктите с отворен код и са под лиценза Apache 2.0. Анотациите и генериците като компоненти на Guice позволяват използването само от Java 5. Това не се отнася за Spring, дори може да се използва с JDK 1.3 и предлага значително повече функции от Guice. Докато последният се фокусира върху DI, Spring също така поддържа транзакции, постоянство и има своя собствена мрежа. Съществуват подпроекти за конфигуриране, сигурност, групови задачи и няколко други.

Дефиницията на зависимости между обекти формира гръбнака на DI рамка. Как се съхраняват и оценяват зависимостите (свързване на обектите) е характерна характеристика. Това показва друга основна разлика между Spring и Guice. Spring позволява както явен дисплей, така и автоматично свързване. Guice използва различен подход: Въпреки че разчита на изрично представяне, той заобикаля бърборещия XML формат, като включва връзките в изходния код, използвайки Java анотации. Тази процедура може да се разбере като смесица между подробния, но интензивен за поддръжка, явен дисплей и автоматичното окабеляване. Spring също позволява създаването на зависимости в Java кода с JavaConfig, но този подпроект все още е в състояние на крайъгълен камък.

производителност

Малка, бърза, ясна

Guice показва своите предимства в производителността пред Spring както в началото на приложението, така и по време на изпълнение, когато става въпрос за създаване на заявените обекти. Guice постига водеща роля при създаването на обекти чрез възможностите за съвпадение на Java 5. (Това обаче трябва да се промени с Spring 3, който ще се базира изцяло на Java 5.) Освен това той не генерира прокси обектите, които Spring използва. Доколко това е уместно на практика, зависи от естеството на заявлението.

В допълнение към техническите свойства и набора от функции, аспекти като сложността са важни при избора на инструмент. Google вижда, че Guice има явно предимство пред Spring от гледна точка на простота, яснота, поддържаемост, ученост и производителност.

Като цяло многобройните сравнения на двете рамки предизвикаха вълнение в съответните кръгове. В крайна сметка обаче не се стига до решение или-или, тъй като макар и двете да са DI контейнери, те имат различен фокус: Guice оставя малък „отпечатък“, докато Spring се предлага като цялостно и мощно решение. Голяма част от неговата XML сложност също е резултат от функции извън DI. Тъй като Guice не покрива тези области, няма истинско съперничество. Съвместното съществуване на двете рамки е възможно, тъй като Guice позволява интегрирането на пролетни зърна.

Планът за Guice 2 - планиран за януари 2009 г. - съдържа редица подобрения, включително слушател на конструкцията и API за самоанализ. Слушателите предлагат входни точки, когато създават обекти, за да закачат вашата собствена логика. Разширението на API е предназначено да разкрие вътрешните елементи на обекта Injector и да позволи пълен достъп до графиката на зависимостите. Това би осигурило отправна точка за инструменти за визуализация например. Пътната карта също така назовава методи на доставчика, с които класовете модули могат да бъдат проектирани по-лесно. По този начин потребителските доставчици могат да извършат по-гъвкаво свързване, което е ефективно само в определен обхват, например.

Заключение

Нито светкавица в тигана

Guice е все още нов, така че има малко продуктивни приложения извън Google. Гореспоменатата уеб рамка Struts2 със сигурност е изключение. Предисторията на Google и използването на AdWords обаче ще гарантират, че Guice няма да завърши като светкавица. Друга индикация за това са модулите на трети страни, които вече съществуват. Това включва компоненти, които дават възможност на Guice да взаимодейства с Hibernate или AWD на Ajax Framework.

Като минус, проектната документация все още е съвсем ясна. Нарастващият брой доклади и инструкции за опит донякъде облекчават този недостатък. От архитектурна гледна точка трябва също да се има предвид, че патентованите анотации затрудняват повторното използване на класове в проекти, които не са Guice. Guice е относително лесен за научаване и лесен за въвеждане - дори в съществуващи проекти. Друго предимство е, че рамката може да се инсталира стъпка по стъпка.

Тобиас Лютике
работи като архитект на решения в министерство в Уелингтън, Нова Зеландия.

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

Терминологичен речник

Код на табела: Повтаряща се, но задължителна схема F-код, който не изобразява бизнес логика.

Инжектор: Компонент, който изпълнява зависимост чрез инжектиране на желания обект.

Модул: Контейнер за връзки, който определя какво да се инжектира.

Обвързване: Връзка между интерфейс и неговото изпълнение.

Обхват: Обхват на инжектиран обект (напр. Заявка, сесия, единичен).

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

Стартиране: Инициализиране на Guice чрез инжектиране на основния обект, за да задейства автоматичното свързване. Това избягва да се налага отново да разпитвате инжектора по-късно за всяко инжектиране.

Анотации: Мета информация, която разработчикът съхранява в изходния код на класовете Java с предшестващ знак "@".

Дженерици: Методи и класове, които могат да бъдат параметризирани с параметри на типа.

Добре окабелени

Окабеляването описва начина, по който рамката управлява зависимости между обектите. Има две основни форми: изричното представяне в XML или Java и автоматичното оценяване от рамката по време на изпълнение (автоматично свързване). И двата варианта могат да бъдат оценени. В случай на автоматично окабеляване, рамката се опитва да разбере връзките между самите компоненти. Въпреки това, тъй като сложността на приложението се увеличава, това създава проблем: производителността се влошава и влошава.

Свободна връзка

Свободни отношения

Dependency Injection (DI) е популярна концепция при разработването на софтуер. Две от основните цели: да се опрости повторната употреба и поддръжка на софтуера чрез свободно свързване на компоненти и да се улесни тестването.

Когато обект A държи препратка към обект B, той обикновено знае неговото изпълнение. Концепцията DI предвижда, че зависимостите между повикващия A и целите B, адресирани от него, вече не се съхраняват в A. Коя реализация на целевия обект В трябва да бъде адресирана конкретно, се съобщава на повикващия само когато е необходимо. За тази цел връзката с бетона В се „инжектира“ в А. Като повикващия, А не знае целевия обект, който да се използва до последното инжектиране.

DI е приложение на парадигмата за инверсия на контрол (IoC), известна също като Холивудския принцип: Не ни се обаждайте, ние ще ви се обаждаме. По този начин инжекцията на зависимости позволява да се използват различни сценарии на използване, без да се налага да се адаптира изходният код на повикващия за това, например когато се добавят нови реализации на целевите обекти. Често срещан пример за такава по-нататъшна цел е услуга като опростен вариант на оригиналната услуга за целите на теста. Ако действителната услуга се нуждае от много ресурси и работи дълго време или изобщо е достъпна само в продуктивната среда, внедряването като фалшив обект (манекен) позволява (по-бързо) тестване.