Guice +类路径扫描 [英] Guice + classpath scanning

问题描述

此刻我正在看Guice，看来它很适合通过模块来显式编程上下文的构建.

I am looking at Guice at the moment and it would appear that its geared towards explicit programmatic building of the context via modules.

现在，我已经相当习惯于使用批注将某些内容放入上下文中，并使用类路径扫描来构建上下文.

Now I am fairly used to using annotations to put something into the context and using classpath scanning to build the context.

现在，我可以很容易地将这个功能"添加到guice中，但是我不想重蹈覆辙，因此，如果有人知道是否已有扩展程序已经做到这一点-请说.

Now I could fairly easily add this "feature" to guice, but I'd rather not reinvent the wheel, so if someone knows if there is an extension that already does this - please say.

但是，我的问题是，这样做会破坏Guice的预期使用和设计吗?我是否错过了在企业应用程序中使用guice的方式/原因的问题?

However, my question is, would I be breaking the desired use and design of Guice by doing this...have I missed the point of how/why guice is meant to be used in an enterprise application?

推荐答案

Guice有一些非常聪明的 JIT绑定，如果不需要实际的绑定(例如，接口到实现等)，则在大多数情况下无需按类型扫描(例如，具体类型).

Guice has some pretty smart JIT binding that makes it unnecessary to scan-per type (concrete types for example) in most situations if there is not an actual binding required (e.g. interface-to-implementation, etc.).

我个人发现春季的组件扫描包装一团糟.默认情况下，您必须显式过滤掉不需要的内容，并默认扫描子包"(在语言中没有任何含义)，而没有简单的方法来只处理您的类型所在的包(没有)难看的过滤器代码和反射)非常脆弱且容易出错. Guice的方法要优雅得多(每个包装都配备了Module).简而言之，我发现自己在大多数时候都会在春季表现出清醒的态度，以保持理智:)

I personally find package-scanning for components in spring to be a mess. The fact that you have to explicitly filter out what you don't want, and get 'sub-packages' (which mean nothing in the language) scanned by default, with no simple way to do just the package your types are in (without ugly filter code and reflection) is extremely fragile and error-prone. Guice's approach to this is far more elegant (convention of Module per package). So in short, I find myself being explicit in spring most of the time to maintain my sanity :)

这篇关于Guice +类路径扫描的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！