Rick,
The code I posted was... overly simplistic. Yes, creating the injector
multiple times could be very costly depending on what is getting
initialized. A more complete solution would use a lazy-loaded injector
singleton:
import com.google.inject.*;
import java.util.*;
public class ServiceCreator {
Injector injector;
private static ServiceCreator INSTANCE = new ServiceCreator();
public static <T> T createService(Class<T> clz) {
return INSTANCE.getInjector().getInstance(clz);
}
private Injector getInjector() {
if (injector == null) {
injector = Guice.createInjector(getModules());
}
return injector;
}
private Collection<Module> getModules() {
HashSet<Module> modules = new HashSet<Module>();
//Add modules here
return modules;
}
}
This keeps the injector as a field on the ServiceCreator instance. It would
be easy enough to tweak the code above such that you could have clients
using the ServiceCreator instance rather than a static method. If you're
trying to do thorough unit testing, I might be tempted to expose the
instance of ServiceCreator rather than static methods so that ServiceCreator
could be put behind an interface.
The main thought was to hide the working of Guice behind a thin facade. I
personally haven't ever needed to do this since our apps use Guice
throughout. But, we have had to wrap external dependencies, and this is how
we've done that (although we do tend to put them behind an interface).
Eric
On Tue, Jan 13, 2009 at 3:37 PM, Rick <[email protected]> wrote:
>
> On Tue, Jan 13, 2009 at 4:03 PM, Eric Anderson
> <[email protected]> wrote:
> > You could always expose a thin static wrapper over the injector so that
> > users don't have to know about the Guice modules or the injector for that
> > matter. What I might do is this:
> >
> >
> > class ServiceCreator {
> > public static <T> T getBar(Class<T> clz) {
> > return Guice.createInjector(modules).getInstance(clz);
> > }
> > }
> >
> > The clients can decide how they want to consume something like this. I'm
> > assuming that you're talking about existing applications that are NOT
> > currently using IoC.
>
>
> Thanks Eric for your reply... in regard to existing applications NOT
> currently using IoC... I guess that's partially true. Since the jar's
> main use will be inside of a tibco ESB in a NEW application, I could
> force them to use Guice.... but I really don't figuring out with them
> at what part should I hook in to get Guice bootstrapped. I was hoping
> to keep the Guice I'm using relatively transparent to them.. so for
> example they would just use the classes provided as singletons or
> static methods to do the basic dao operations (ie
> updateEmployee(Employee e).
>
> In regard to the code posted above I have to admit I'm a bit confused
> by how it would be used. I suppose the real implementation would be
> called getService(Class<T> clz) ?
>
> and the end user would have to call something like...
>
> EmployeeService service = ServiceCreator.getService(EmployeeService.class)
> ?
>
> If so I'm confused though, wouldn't the end users be calling
> Guice.createInjector(modules) a bunch of times?
>
> There would also be the need to return other Service classes to the
> end user as well. Or does it not hurt to call createInjector multiple
> times?
>
> Thanks again for the help.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
