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.
