我对EJB和像JBoss这样的完整应用程序服务器相当陌生,在我职业生涯的大部分时间里,他都使用专用的独立Java应用程序编写并使用Java EE。我想知道将常用设计模式适应EJB3和JBoss的最佳方法:静态工厂模式。事实上,这是Joshua Bloch的Effective Java书籍(第2版)中的第1项
我目前正在与以下工厂合作:
public class CredentialsProcessorFactory {
private static final Log log = LogFactory.getLog(CredentialsProcessorFactory.class);
private static Map<CredentialsType, CredentialsProcessor> PROCESSORS =
new HashMap<CredentialsType, CredentialsProcessor>();
static {
PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
}
private CredentialsProcessorFactory() {}
public static CredentialsProcessor getProcessor(CredentialsType type) {
CredentialsProcessor p = PROCESSORS.get(type);
if(p == null)
throw new IllegalArgumentException("No CredentialsProcessor registered for type " + type.toString());
return p;
}
但是,在CredentialsProcessor的实现类中,我需要注入资源,例如PersistenceContext
,因此我将CredentialsProcessor
接口设为@Local
接口,并且每个impl标记为与@Stateless
。现在我可以在JNDI中查找它们并使用注入的资源。
但现在我断了连接,因为我不再使用工厂了。我的第一个想法是更改getProcessor(CredentialsType)
方法以执行JNDI查找并返回所需的SLSB实例,但之后我需要配置并传递适当的限定JNDI名称。在我走这条路之前,我想对接受的做法做更多的研究。
如何在EJB3 / Java EE中处理此设计模式? -
答案 0 :(得分:-1)
使用EJB3,您通常不需要进行JNDI查找。 EJB3支持dependency injection个EJB和其他几种类型的资源。如果您的bean属性使用@EJB
注释,则依赖项将自动由容器注入。
不必进行JNDI查找意味着您可以像POJO一样测试EJB以进行单元测试。您可以手动注入依赖项的模拟实现并测试它们,而无需将它们部署在容器中。
答案 1 :(得分:-1)
当你开始使用工厂和“真正的”Java POJO代码时,你基本上需要依赖JNDI。
依赖注入仅适用于EJB服务器的托管组件,而且基本上是Servlet和EJB。
当你在谈论想要引用EJB的通用java代码时,他们需要通过JNDI自己查找资源。
在这种情况下,最好的做法是编写一个包含静态函数的包装器查找类来执行JNDI查找,而不是直接在每个实现中调用JNDI。然后在您的实现中使用它。
这只是一个通用的整体规则。
现在,针对您的具体情况,请考虑这一点。
你有:
static {
PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
}
这与以下内容没有什么不同:
static {
PROCESSORS.put(CredentialsType.CSV, "java:comp/env/ejb/CSVCredentialProcessorSessionBean");
}
然后,在你的getProcessor()代码中:
Context c = new InitialContext();
return (CredentialsProcessor) c.lookup(PROCESSORS.get(type));
基本上看,代码是相同的,您的工厂界面与客户端相同。
你必须“硬编码”JNDI查找键,但你现在无论如何“硬编码”类名,那么这有什么不同呢?
容器之间存在一些潜在的可移植性问题,因为每个人似乎都喜欢为bean名称使用不同的JNDI标识符。其中大部分可以在部署中进行调整,但如果没有,那么您可以将这些密钥拉出到配置文件中,或者其他任何内容。
在Java EE 6中,保证了可移植名称。如果您今天没有移植容器,那么根本不用担心这个问题。
所以,基本上,它根本不是真正的脱节。