Oh I've got the list already, trust me. ServiceFactory is configured
in an XML file:
.
.
.
<Binding interfaceName="com.yada.yada.yada.checkout.CheckoutService">
<Option name="Local"
value="com.yada.yada.yada.checkout.CheckoutServiceImpl"/>
<Option name="jndi" value="ejb/com/yada/yada/yada/
WorkflowServiceSB"/>
</Binding>
.
.
.
On Mar 25, 4:40 pm, Christian <[email protected]> wrote:
> 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.
