Yes that's exactly what I was thinking. The only problem is collecting collecting the list. Maybe you could use some sort of reflection on that ServiceFactory ? Or just go by hand and make that list.
2010/3/25 Russ <[email protected]> > 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]> > <google-guice%[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]<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.
