On 29 March 2010 08:26, yarco <[email protected]> wrote: > Whats the difference between @Provider methods in Modules and > Providers interfaces.
nothing really, they behave the same - @Provides methods are just easier to write > Basically what I understand that you call your > custom provider whenever you need an object (provider.get()) and > @Providers method is called whenever you need start a new Scope > (Prototype for example). no, both @Provides methods and Providers are called to satisfy an instance request scopes are applied independently of @Provides / Providers according to the binding > Can somebody explain the benefit of > implementing a Provider? Basically I see a big drawback that by using > providers guice dependencies get scattered all over your application > code. > Providers should actually reduce the amount of Guice dependencies, as you can do the wiring yourself if you want (whether that's a good thing or not is another matter!) - same with @Provides, there's not much difference between them really from the wiki: http://code.google.com/p/google-guice/wiki/ProvidesMethods http://code.google.com/p/google-guice/wiki/ProviderBindings "When your @Provides methods start to grow complex, you may consider moving them to a class of their own." - so basically if you have complex behavior you might find a Provider class a better fit wrt. dependencies being scattered over app code - if you use JSR330 annotations then you're using a standard that's recognized by Guice, Spring, and various other DI frameworks - and if you're not using DI then the annotations are simply ignored (then you don't even need the annotation jar on the runtime classpath) And the second question is about Springs <context:component-scan base- > package="x.y.service">. Will guice have anything like this? As I know > that it is possible to annotate an interface and specify the default > Impl for it, but again, I don't want my API to have a dependency on > guice. > there are a few scanning extensions available - the benefit of a programmatic binding API is that you can drive it from XML config, classpath scanning, etc. without the core Guice library having to know anything about it http://www.mail-archive.com/[email protected]/msg02285.html I've got code that does scanning for Plexus metadata/annotations and I'm just finishing up a simple extension that works with JSR330 qualifiers like @Named to find and bind implementations -- > 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. > -- Cheers, Stuart -- 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.
