我正在阅读JavaEE 6教程，在阅读SessionBean和CDI部分时，我遇到了一些疑问。
1）根据我的理解，@EJB注释会注入一个SessionBean，从而导致使用Dependency Inject模式。我知道这种模式旨在扭转谁建立什么对象的责任。因此，它不是创建它拥有依赖项的某个类，而是在构造函数中接收它们。但是，@EJB注释如何减轻不注入依赖项的问题？ @Inject注释也是如此。
2）我有这个实用程序类（只包含静态方法），它将日期格式化为多种格式（yyyy-MM-dd，dd-MM-yyyy等...）。对这些方法使用无状态会话Bean是否更好？还是应该保留Utility类？如果为此使用EJB，使用它或使用@Inject注释使用bean有什么区别？
3）使用依赖注入时，使用服务定位器或工厂模式是否有意义？ （虽然我已经看到Service Locater被记录为反模式）。
答案 0 :(得分：2)
@EJB和@Inject缓解了不注入的问题，通过...注入（duh！;））
将此实用程序方法保留在这些类中。 EJB用于事务管理，资源使用throtteling，限制基于用户角色的方法访问等。对于您的实用程序方法，这似乎都不是必需的。
最多可以通过CDI使该实用程序类可注入：为它定义一个接口并创建一个生成器方法。通常这甚至是过度杀伤，但这取决于你的班级及其用法的确切扩展。
通过注入，您仍然可以拥有工厂（生产者是一种工厂），但客户端没有明确使用工厂。客户端声明了依赖关系，CDI可以使用“工厂”（生产者）来满足这一要求。
答案 1 :(得分：1)
没有。依赖注入不仅仅是避免创建依赖项。它还涉及避免向容器询问其依赖性。容器将依赖项注入组件，而不是向容器请求依赖项。我不明白你的意思是“不注入依赖关系的问题”。请澄清。
当您需要由容器围绕方法添加事务，安全性和/或远程处理方面时，通常会使用会话Bean。如果它只是一个实用程序类，则没有理由将它作为会话bean。
不，这没有意义。去除注入的主要目标是替换servce定位器和/或工厂的使用，以便让容器将依赖注入bean。这就是使代码易于测试的原因，因为您可以在单元测试中将假依赖项（模拟对象）注入bean中。