I will give a second answer, but you really should have opened a second question...

First of all: you rarely ever implement a provider. Guice will automagically create them for you. To explain this: When I bind a class Foo as follows:

bind(Foo.class).to(FooImpl.class) 

You can inject in you class either Foo or Provider<Foo>. Guice will create the provider for you.

The reason why you should not implement the provider yourself, is that AOP is not working on instances that where created with a call to new. When you use a debugger to look at the run time instance of an injected object which uses interceptors you will notice that Guice created a subclass on the fly allowing it to intercept the method calls.

To your example:

The main problem is, that ProductModel should not be injected. It is a domain object and holds data. These kind of objects should not be created/managed by DI. Instead you code is responsible to create/retrieve and store the model from its persistent state. The presenter has now two different dependencies. One is the model which lives outside of DI and one is the view which can be handled by DI (just as a side note: if you need the same instance of the view to be injected on more than one object you must place it in a (custom-) scope. But answers to scopes deserve a new question).

To solve the above dilemma Guice offers assisted injection. This allows you to write a code like to following:

public class ProductPresenter { public interface Factory { createPresenter(ProductModel model); } @Inject ProductPresenter(@Assisted ProductModel model, ProductView view) { this.model = model; this.view = view; } } 

you then bind the factory as follows:

install(new FactoryModuleBuilder().build(ProductPresenter.Factory.class)); 

This allows you to mix DI with non DI objects

I will give a second answer, but you really should have opened a second question...

First of all: you rarely ever implement a provider. Guice will automagically create them for you. To explain this: When I bind a class Foo as follows:

bind(Foo.class).to(FooImpl.class) 

You can inject in you class either Foo or Provider<Foo>. Guice will create the provider for you.

The reason why you should not implement the provider yourself, is that AOP is not working on instances that where created with a call to new. When you use a debugger to look at the run time instance of an injected object which uses interceptors you will notice that Guice created a subclass on the fly allowing it to intercept the method calls.

To your example:

The main problem is, that ProductModel should not be injected. It is a domain object and holds data. These kind of objects should not be created/managed by DI. Instead you code is responsible to create/retrieve and store the model from its persistent state. The presenter has now two different dependencies. One is the model which lives outside of DI and one is the view which can be handled by DI (just as a side note: if you need the same instance of the view to be injected on more than one object you must place it in a (custom-) scope. But answers to scopes deserve a new question).

To solve the above dilemma Guice offers assisted injection. This allows you to write a code like to following:

public class ProductPresenter { public interface Factory { createPresenter(ProductModel model); } @Inject ProductPresenter(@Assisted ProductModel model, ProductView view) { this.model = model; this.view = view; } } 

you then bind the factory as follows:

install(new FactoryModuleBuilder().build(ProductPresenter.Factory.class)); 

Guice will create an implementation of the ProductPresenter.Factory interface on the fly. The created instance will get the arguments passed to the factory method put into the constructor. Also AOP is working on the created instance. This way you can mix DI with non DI objects.