Guice – a lightweight DI framework alternative to Spring

What is Guice?

To quote from the Guice official page

“Guice alleviates the need for factories and the use of new in your Java code. Think of Guice’s @Inject as the new new. Guice embraces Java’s type safe nature, especially when it comes to features introduced in Java 5 such as generics and annotations. You might think of Guice as filling in missing features for core Java. Ideally, the language itself would provide most of the same features, but until such a language comes along, we have Guice”

If you’ve used Spring or other DI frameworks you’re probably familiar to the above ideas. I’ll present in this article how to get started with Guice in a non-web application. I’ll detail the web side in a future article.

Is it better than Spring?

Well, this is one of those talks that could last forever. Like EJB vs Spring, Struts vs JSF and so on. It’s a matter of choice. I can say one thing though: if you need just  DI in your application go for Guice. It’s very lightweight, it’s type safe and it’s faster than Spring.

Using Guice for a non-web application

Suppose you have an application and the class that contains the main method its called Application. When using Guice the approach is a little changed. Besides starting the application you’ll also want a way to trigger the dependency injection. In order to to this you must have an “entry-point” that “manually” triggers the creation of the graph of objects that will get injected and only after that starts the actual application logic. We’ll call the class responsible for these 2 things the Bootstrap class. We also need to create a Module by extending the AbstractModule class. Quoting from the Java Doc of the Module interface:

A module contributes configuration information, typically interface bindings, which will be used to create an Injector. A Guice-based application is ultimately composed of little more than a set of Modules and some bootstrapping code.

Let’s see the code:

The Bootstrap class:

package com.insidecoding.guice;
import com.google.inject.Guice;

Continue reading

How to inject Spring beans into Servlets

This can be achieved in 3 simple steps:

1. Implement HttpRequestHandler

First of all your servlet class must implement the org.springframework.web.HttpRequestHandlerinterface and provide an implementation for the handleRequest() method just like you would override doPost().

2. Declare the servlet as a Spring Bean

You can do this by either adding the @Component(“myServlet”) annotation to the class, or declaring a bean with a name myServlet in applicationContext.xml.

   @Component("myServlet")
   public class MyServlet implements HttpRequestHandler {
...

3. Declare in web.xml a servlet named exactly as the Spring Bean

The last step is to declare a new servlet in web.xml that will have the same name as the previously declared Spring bean, in our case myServlet. The servlet class must be org.springframework.web.context.support.HttpRequestHandlerServlet.

The Generic DAO pattern in Java with Spring 3 and JPA 2.0

One thing that annoys me the most is code duplication. The DAO layer is the perfect candidate for this kind of situation. Often, developers forget about OOP, polymorphism and design patterns and just copy&paste code, change the name of the class and voila, we have a brand “new” BankDao class. I’ll present you how to implement a generic DAO pattern to avoid code duplication and preserve type safety in the same time. Why would you care about type safety and just don’t go use the EntityManager’s generic methods. Well, for various reasons:

  1. You know for sure which entity objects can be persisted
  2. You avoid a lot of explicit casts which are error prone
  3. The code is cleaner and  very easy to follow
  4.  You actually apply OOP principles like inheritance and polymorphism. ;)

The purpose of this article is not to get you familiar with the DAO pattern, but to show you a better way of using it. You can find a complete reference about DAO here: DataAccessobject.

The Generic DAO interface

Let’s get started. First of all this article assumes you are using Spring 3 (although this can be easily adapted to Spring 2.5) and JPA 2.0 in you project and the initial configuration is in place:  you already have a data sources declared, an entity manager factory, etc.  The application is basically up&running.

The foundation of using a Generic DAO is the CRUD operations that you can perform on each entity. And this is the least you can have. Additional generic methods can be defined like: count all objects of a specific type; execute generic queries based on some parameters, etc. You’ll see a sample bellow for countAll().

The core of this pattern will be an interface called, surprisingly, GenericDao and its implementation Continue reading