EJB3 / JBoss的avaStatic工厂模式

时间:2010-03-29 23:11:51

标签: java jboss java-ee ejb-3.0

我对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中处理此设计模式? -

2 个答案:

答案 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中,保证了可移植名称。如果您今天没有移植容器,那么根本不用担心这个问题。

所以,基本上,它根本不是真正的脱节。