Ah. I think I'm starting to see the light.
class ServiceFactoryWrapper {
<T extends Service> T get(Class<T> serviceClass, ServiceHandleType
type) {
return (T)ServiceFactory.getInstance(serviceClass, type);
}
}
My production module could look like this:
ServiceFactoryWrapper sfWrapper = new ServiceFactoryWrapper();
bind(CheckoutService.class)
.annotatedWith(Web.class)
.to(sfWrapper.get(CheckoutService.class, ServiceFactory.WEB);
bind(CheckoutService.class)
.annotatedWith(Client.class)
.to(sfWrapper.get(CheckoutService.class, ServiceFactory.Client);
Given a list of Service classes I could certainly put this in some
sort of loop.
My test module would look like this:
bind(CheckoutService.class).to(MockCheckoutService.class);
because despite the @Web binding in the impl class that requires an
impl of CheckoutService, I don't want to inject a ServiceFactory.WEB
implementation of CheckoutService.
Thanks!
-Russ
On Mar 25, 4:10 pm, Christian <[email protected]> wrote:
> Hi Russ,
>
> Question 1 : For the constants ServiceFactory.CLIENT and such, annotations
> seems a perfect fit. You can create annotations @Web, @Client @Local and
> create different bindings in the module :
>
> bind(CheckoutService.class).annotatedWith(Web.class).to whatever
> bind(CheckoutService.class).annotatedWith(Client.class).to ...
> etc
>
> then you have the desired instance injected with the annotation :
>
> @Inject
> @Web
> private CheckoutService service ;
>
> You do need test modules in order to bind CheckoutService to some
> CheckoutMockService that performs nothing.
>
> Question 2 : do not create one module per service... You could create one
> module for all services, but I'd tend to try to break it down into logical
> pieces. You can also save a lot of production bindings with implicit
> bindings ( interface annotated with @ImplementedBy).
> Then you can override explicitely for tests.
>
> Question 3 : You can do like you want. When the application is all guicified
> the injector construction will most certainly take place at bootstrap
> (Servlet init or public static void main)
>
> If you want only one part to be guicified it can work very well. If I were
> you I'd build one injector in that mighty ServiceFactory and then in this
> factory I delegate the services constructions to guice for the services you
> have guicified already.
>
> And if those guicified services need services that are not guicified
> already, bind a provider that delegates to ServiceFactory. Then you can take
> those off as you guicify more stuff.
>
> 2010/3/25 Russ <[email protected]>
>
> > We are investigating introducing Guice into a large code base. By
> > "large" I mean over 13,000 source Java files consisting of over 2.9
> > million lines of code (not including a paltry 261 unit test source
> > files consisting of 64,000 lines of code).
>
> > We have a mandate from on high to improve the quantity and coverage of
> > our unit tests and I think DI with Guice is a good fit. It's small
> > enough (that is, it's not Spring) that I think it will eventually be
> > accepted here but I've got some convincing of others to do first, so
> > I've got some questions that I think those that need convincing will
> > ask.
>
> > It would mean (incrementally, I hope!) changing classes from
> > instantiating their own dependees to letting Guice do it for them.
> > Most of our classes use the factory pattern for getting their
> > dependees, a la:
>
> > final CheckoutService checkoutService =
>
> > (CheckoutService)ServiceFactory.getInstance(CheckoutService.class,
>
> > ServiceFactory.CLIENT);
>
> > where the CLIENT constant signals that the factory should return an
> > implementation of CheckoutService that can be used from the "client"
> > tier of the code base (other members are WEB, meaning that the
> > implementation should be only used in the web tier (the servlet), and
> > LOCAL, meaning a POJO that lives in the app server).
>
> > Question 1: What's the best way to annotate things so that the
> > depender class can be unit tested with a dummy CheckoutService, but
> > still get a reference to the CLIENT implementation in the real
> > application? Do I need a RealServices module and a TestServices
> > module (or at least a bunch of TestFooService modules)?
>
> > Question 2: Do I create a Module per service, or lump all the Service
> > bindings in One Big Module? Or some other way? At last count, we've
> > got about 250 service interfaces.
>
> > Question 3: Where should I start making things guicy, i.e., where is
> > the Injector going to live? Client-side, should I start at the edge
> > of the object graph? Or in the main() method of my launcher class?
> > Or is it OK to create Injectors at the edges and move them "in" to the
> > graph as I guicify things?
>
> > Thanks in advance for your time.
>
> > -Russ
>
> > --
> > 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]<google-guice%[email protected]>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-guice?hl=en.
--
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.
