Example use-cases for using Dependency Injection with the Play Framework

Question

I am a big fan of Dependency Injection and the Play Framework, but am having trouble seeing how the two could be exploited together.

There are modules for Spring and Guice, but the way that Play works makes it hard for me to see how DI could be beneficial beyond some quite simple cases.

A good example of this is that Play expects JPA work to be done by static methods associated with the entity in question:

@Entity
Person extends Model {
    public static void delete(long id) {
        em().find(id).remove();
    }

    //etc
}

So there is no need for a PersonManager to be injected into controllers in the way it might for a Spring J2EE application. Instead a controller just calls Person.delete(x).

Obviously, DI is beneficial when there are interfaces with external systems, as the concrete implementation can be mocked for testing etc., but I don't see much benefit for a self-contained Play application.

Does anyone have any good examples? Does anyone use it to inject a Manager-style class into Controllers so that a number of operations can be done within the same transaction, for example?

Answer 1

I believe from this sentence you wrote:

"Does anyone have any good examples? Does anyone use it to inject a Manager-style class into Controllers so that a number of operations can be done within the same transaction, for example?"

that before answering the DI question I should note something: transactions are managed automatically by Play. If you check the model documentation you will see that a transaction is automatically created at the beginning of a request, and committed at the end. You can roll it back via JPA or it will be rolled back if an exception is raised.

I mention this because from the wording of your sentence I'm not sure if you are aware of this.

Now, on DI itself, in my (not-so-extensive) experience with DI, I've seen it used mainly to:

• Load the ORM (Hibernate) factory/manager
• Load Service classes/DAOs into another class to work with them

Sure, there are more scenarios, but these probably cover most of the real usage. Now:

• The first one is irrelevant to Play as you get access to your JPA object and transaction automatically
• The second one is quite irrelevant too as you mainly work with static methods in controllers. You may have some helper classes that need to be instantiated, and some may even belong to a hierarchy (common interface) so DI would be beneficial. But you could just as well create your won factory class and get rid of the jars of DI.

There is another matter to consider here: I'm not so sure about Guice, but Spring is not only DI, it also provides a lot of extra functionalities which depend on the DI module. So maybe you don't want to use DI in Play, but you want to take advantage of the Spring tools and they will use DI, albeit indirectly (via xml configuration).