Guice срещу Spring - Инжектиране на зависимост

1. Въведение

Google Guice и Spring са две стабилни рамки, използвани за инжектиране на зависимости. И двете рамки обхващат всички понятия за инжектиране на зависимост, но всяка от тях има свой собствен начин за прилагането им.

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

2. Зависимости на Maven

Нека започнем с добавяне на зависимостите Guice и Spring Maven в нашия файл pom.xml :

 org.springframework spring-context 5.1.4.RELEASE   com.google.inject guice 4.2.2 

Винаги можем да осъществим достъп до най - новите зависимости от пролетен контекст или guice от Maven Central.

3. Конфигурация за инжектиране на зависимост

Инжектирането на зависимости е програмна техника, която използваме, за да направим нашите класове независими от техните зависимости.

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

3.1. Пролетно окабеляване

Spring декларира конфигурациите за инжектиране на зависимост в специален конфигурационен клас. Този клас трябва да бъде анотиран от анотацията @Configuration . Контейнерът Spring използва този клас като източник на дефиниции на боб.

Класовете, управлявани от Spring, се наричат Spring spring.

Spring използва анотацията @Autowired за автоматично свързване на зависимостите . @Autowired е част от вградените основни пояснения на Spring. Можем да използваме @Autowired за променливи на членове, методи за задаване и конструктори.

Spring също поддържа @Inject. @Inject е част от Java CDI (Contexts and Dependency Injection), която определя стандарт за инжектиране на зависимости.

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

@Component public class UserService { @Autowired private AccountService accountService; }
@Component public class AccountServiceImpl implements AccountService { }

На второ място, нека създадем конфигурационен клас, който да използваме като източник на зърна, докато зареждаме контекста на нашето приложение:

@Configuration @ComponentScan("com.baeldung.di.spring") public class SpringMainConfig { }

Имайте предвид, че също сме отбелязали UserService и AccountServiceImpl с @Component, за да ги регистрираме като боб. Това е анотацията @ComponentScan, която ще каже на Spring къде да търси коментирани компоненти.

Въпреки че сме коментирали AccountServiceImpl , Spring може да го преобразува в AccountService, тъй като реализира AccountService .

След това трябва да дефинираме контекст на приложението за достъп до зърната. Нека просто отбележим, че ще се позоваваме на този контекст във всичките ни пролетни единични тестове:

ApplicationContext context = new AnnotationConfigApplicationContext(SpringMainConfig.class);

Сега по време на изпълнение можем да извлечем екземпляра A ccountService от нашия боб UserService :

UserService userService = context.getBean(UserService.class); assertNotNull(userService.getAccountService());

3.2. Обвързване на Guice

Guice управлява своите зависимости в специален клас, наречен модул. Модулът Guice трябва да разшири класа AbstractModule и да замени неговия метод configure () .

Guice използва обвързване като еквивалент на окабеляването през пролетта. Просто казано, обвързването ни позволява да дефинираме как зависимостите ще бъдат инжектирани в клас . Обвързването на Guice се декларира в метода configure () на нашия модул .

Вместо @Autowired , Guice използва анотацията @Inject, за да инжектира зависимостите.

Нека създадем еквивалентен пример на Guice:

public class GuiceUserService { @Inject private AccountService accountService; }

На второ място, ще създадем модулния клас, който е източник на нашите дефиниции за обвързване:

public class GuiceModule extends AbstractModule { @Override protected void configure() { bind(AccountService.class).to(AccountServiceImpl.class); } }

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

След това трябва да дефинираме инжектор, използвайки GuiceModule, за да получим екземпляри от нашите класове. Нека само отбележим, че всички наши тестове на Guice ще използват този инжектор :

Injector injector = Guice.createInjector(new GuiceModule());

На последно място, по време на изпълнение ние извлечете GuiceUserService например с не-нула accountService зависимостта:

GuiceUserService guiceUserService = injector.getInstance(GuiceUserService.class); assertNotNull(guiceUserService.getAccountService());

3.3. Анотация на @Bean на Spring

Spring също предоставя анотация на ниво метод @Bean, за да регистрира боб като алтернатива на своите анотации на ниво клас като @Component . Връщаната стойност на коментиран метод @Bean се регистрира като боб в контейнера.

Да кажем, че имаме екземпляр на BookServiceImpl , който искаме да предоставим за инжектиране. Можем да използваме @Bean, за да регистрираме нашия екземпляр:

@Bean public BookService bookServiceGenerator() { return new BookServiceImpl(); }

И сега можем да получим боб на BookService :

BookService bookService = context.getBean(BookService.class); assertNotNull(bookService);

3.4. Guice's @Provides Annotation

As an equivalent of Spring's @Bean annotation, Guice has a built-in annotation @Provides to do the same job. Like @Bean, @Provides is only applied to the methods.

Now let's implement the previous Spring bean example with Guice. All we need to do is to add the following code into our module class:

@Provides public BookService bookServiceGenerator() { return new BookServiceImpl(); }

And now, we can retrieve an instance of BookService:

BookService bookService = injector.getInstance(BookService.class); assertNotNull(bookService);

3.5. Classpath Component Scanning in Spring

Spring provides a @ComponentScan annotation detects and instantiates annotated components automatically by scanning pre-defined packages.

The @ComponentScan annotation tells Spring which packages will be scanned for annotated components. It is used with @Configuration annotation.

3.6. Classpath Component Scanning in Guice

Unlike Spring, Guice doesn't have such a component scanning feature. But it's not difficult to simulate it. There are some plugins like Governator that can bring this feature into Guice.

3.7. Object Recognition in Spring

Spring recognizes objects by their names. Spring holds the objects in a structure which is roughly like a Map. This means that we cannot have two objects with the same name.

Bean collision due to having multiple beans of the same name is one common problem Spring developers hit. For example, let's consider the following bean declarations:

@Configuration @Import({SpringBeansConfig.class}) @ComponentScan("com.baeldung.di.spring") public class SpringMainConfig { @Bean public BookService bookServiceGenerator() { return new BookServiceImpl(); } }
@Configuration public class SpringBeansConfig { @Bean public AudioBookService bookServiceGenerator() { return new AudioBookServiceImpl(); } }

As we remember, we already had a bean definition for BookService in SpringMainConfig class.

To create a bean collision here, we need to declare the bean methods with the same name. But we are not allowed to have two different methods with the same name in one class. For that reason, we declared the AudioBookService bean in another configuration class.

Now, let's refer these beans in a unit test:

BookService bookService = context.getBean(BookService.class); assertNotNull(bookService); AudioBookService audioBookService = context.getBean(AudioBookService.class); assertNotNull(audioBookService);

The unit test will fail with:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'AudioBookService' available

First, Spring registered the AudioBookService bean with “bookServiceGenerator” name in its bean map. Then, it had to override it by the bean definition for BookService due to the “no duplicate names allowed” nature of the HashMap data structure.

Lastly, we can overcome this issue by making bean method names unique or setting the name attribute to a unique name for each @Bean.

3.8. Object Recognition in Guice

Unlike Spring, Guice basically has a Map structure . This means that we cannot have multiple bindings to the same type without using additional metadata.

Guice provides binding annotations to enable defining multiple bindings for the same type. Let's see what happens if we have two different bindings for the same type in Guice.

public class Person { }

Now, let's declare two different binding for the Person class:

bind(Person.class).toConstructor(Person.class.getConstructor()); bind(Person.class).toProvider(new Provider() { public Person get() { Person p = new Person(); return p; } });

And here is how we can get an instance of Person class:

Person person = injector.getInstance(Person.class); assertNotNull(person);

This will fail with:

com.google.inject.CreationException: A binding to Person was already configured at GuiceModule.configure()

We can overcome this issue by just simply discarding one of the bindings for the Person class.

3.9. Optional Dependencies in Spring

Optional dependencies are dependencies which are not required when autowiring or injecting beans.

For a field that has been annotated with @Autowired, if a bean with matching data type is not found in the context, Spring will throw NoSuchBeanDefinitionException.

However, sometimes we may want to skip autowiring for some dependencies and leave them as nullwithout throwing an exception:

Now let's take a look at the following example:

@Component public class BookServiceImpl implements BookService { @Autowired private AuthorService authorService; }
public class AuthorServiceImpl implements AuthorService { }

As we can see from the code above, AuthorServiceImpl class hasn't been annotated as a component. And we'll assume that there isn't a bean declaration method for it in our configuration files.

Now, let's run the following test to see what happens:

BookService bookService = context.getBean(BookService.class); assertNotNull(bookService);

Not surprisingly, it will fail with:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'AuthorService' available

We can make authorService dependency optional by using Java 8's Optional type to avoid this exception.

public class BookServiceImpl implements BookService { @Autowired private Optional authorService; }

Now, our authorService dependency is more like a container that may or may not contain a bean of AuthorService type. Even though there isn't a bean for AuthorService in our application context, our authorService field will still be non-null empty container. Hence, Spring won't have any reason to throw NoSuchBeanDefinitionException.

As an alternative to Optional, we can use @Autowired‘s required attribute, which is set to true by default, to make a dependency optional. We can set the required attribute to false to make a dependency optional for autowiring.

Hence, Spring will skip injecting the dependency if a bean for its data type is not available in the context. The dependency will remain set to null:

@Component public class BookServiceImpl implements BookService { @Autowired(required = false) private AuthorService authorService; }

Sometimes marking dependencies optional can be useful since not all the dependencies are always required.

With this in mind, we should remember that we'll need to use extra caution and null-checks during development to avoid any NullPointerException due to the null dependencies.

3.10. Optional Dependencies in Guice

Just like Spring, Guice can also use Java 8's Optional type to make a dependency optional.

Let's say that we want to create a class and with a Foo dependency:

public class FooProcessor { @Inject private Foo foo; }

Now, let's define a binding for the Foo class:

bind(Foo.class).toProvider(new Provider() { public Foo get() { return null; } });

Now let's try to get an instance of FooProcessor in a unit test:

FooProcessor fooProcessor = injector.getInstance(FooProcessor.class); assertNotNull(fooProcessor);

Our unit test will fail with:

com.google.inject.ProvisionException: null returned by binding at GuiceModule.configure(..) but the 1st parameter of FooProcessor.[...] is not @Nullable

In order to skip this exception, we can make the foo dependency optional with a simple update:

public class FooProcessor { @Inject private Optional foo; }

@Inject doesn't have a required attribute to mark the dependency optional. An alternative approach to make a dependency optional in Guice is to use the @Nullable annotation.

Guice tolerates injecting null values in case of using @Nullable as expressed in the exception message above. Let's apply the @Nullable annotation:

public class FooProcessor { @Inject @Nullable private Foo foo; }

4. Implementations of Dependency Injection Types

In this section, we'll take a look at the dependency injection types and compare the implementations provided by Spring and Guice by going through several examples.

4.1. Constructor Injection in Spring

In constructor-based dependency injection, we pass the required dependencies into a class at the time of instantiation.

Let's say that we want to have a Spring component and we want to add dependencies through its constructor. We can annotate that constructor with @Autowired:

@Component public class SpringPersonService { private PersonDao personDao; @Autowired public SpringPersonService(PersonDao personDao) { this.personDao = personDao; } }

Starting with Spring 4, the @Autowired dependency is not required for this type of injection if the class has only one constructor.

Let's retrieve a SpringPersonService bean in a test:

SpringPersonService personService = context.getBean(SpringPersonService.class); assertNotNull(personService);

4.2. Constructor Injection in Guice

We can rearrange the previous example to implement constructor injection in Guice. Note that Guice uses @Inject instead of @Autowired.

public class GuicePersonService { private PersonDao personDao; @Inject public GuicePersonService(PersonDao personDao) { this.personDao = personDao; } }

Here is how we can get an instance of GuicePersonService class from the injector in a test:

GuicePersonService personService = injector.getInstance(GuicePersonService.class); assertNotNull(personService);

4.3. Setter or Method Injection in Spring

In setter-based dependency injection, the container will call setter methods of the class, after invoking the constructor to instantiate the component.

Let's say that we want Spring to autowire a dependency using a setter method. We can annotate that setter method with @Autowired:

@Component public class SpringPersonService { private PersonDao personDao; @Autowired public void setPersonDao(PersonDao personDao) { this.personDao = personDao; } }

Whenever we need an instance of SpringPersonService class, Spring will autowire the personDao field by invoking the setPersonDao() method.

We can get a SpringPersonService bean and access its personDao field in a test as below:

SpringPersonService personService = context.getBean(SpringPersonService.class); assertNotNull(personService); assertNotNull(personService.getPersonDao());

4.4. Setter or Method Injection in Guice

We'll simply change our example a bit to achieve setter injection in Guice.

public class GuicePersonService { private PersonDao personDao; @Inject public void setPersonDao(PersonDao personDao) { this.personDao = personDao; } }

Every time we get an instance of GuicePersonService class from the injector, we'll have the personDao field passed to the setter method above.

Here is how we can create an instance of GuicePersonService class and access its personDao fieldin a test:

GuicePersonService personService = injector.getInstance(GuicePersonService.class); assertNotNull(personService); assertNotNull(personService.getPersonDao());

4.5. Field Injection in Spring

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

В случай на инжектиране на зависимост на базата на поле, ние инжектираме зависимостите, като ги маркираме с @Autowired или @Inject .

4.6. Полево инжектиране в Guice

Както споменахме в горния раздел, вече покрихме инжектирането на поле за Guice с помощта на @Inject .

5. Заключение

В този урок разгледахме няколко основни разлики между рамките на Guice и Spring в техните начини за внедряване на инжектиране на зависимост. Както винаги, примерните кодове на Guice и Spring са приключили на GitHub.