Java EE EJB 注入中的两个耦合类

Java EE EJB injection in two coupled classes

我有以下 classes:

public class ScoringService {

    @Inject
    public ServiceOne service1;

    @Inject
    public ServiceTwo service2;

    @Inject
    public DecisionHandler dh;

    public void scoreData() {

        Data d1 = service1.getData();
        Data d2 = service2.getData();
        Data newData = process(d1, d2)

        dh.handle(newData);
    }

}

public class DecisionHandler {

    @Inject
    public ServiceOne service1;

    public void handle(Data newData) {
        service.updateData(newData);
    }
}

ServiceOneServiceTwo 是带@Stateless 注释的 EJB。

我知道容器为无状态 EJB 创建池,也为注入和其他东西创建代理。所以在我的例子中,在 ScoringServiceDecisionHandler 的两个实例中是否有可能会有两个不同的 ServiceOne 实例?因此会有过度生成的 ServiceOne 个实例?我的意思是注入 DecisionHandlerScoringService 将被调用用于一个目的,不需要两个持有 ServiceOne.

的两个实例

我将 DecisionHandler 设为单独的 class 以分解集中在一个 ServiceClass 中的复杂逻辑。我也可以使用方法将 DecisionHandler 作为普通的 class 并在调用期间实例化它。我应该如何理解我应该使它成为 EJB?

我开始认为它是一些过时的东西,仅适用于具有胖客户端的客户端-服务器模型,以帮助通过远程调用对服务器 EJB 进行调用,并且不应将其用于具有 web 或 self-运行 计算程序。是真的吗?

So in my case is it possible that there will be two different instances of ServiceOne in both instances of ScoringService and DecisionHandler?

如果你在谈论 @Stateless 那么它取决于容器(应用程序服务器)。您不应该对服务于客户端的 EJB 的数量做出任何假设。所以你可以有一个或两个,这是不可预测的。

I made the DecisionHandler a separate class to disassemble complex logic concentrated in one ServiceClass. Also I can make the DecisionHandler as a plain class with a method and instantiate it during call. How should I understand that I should make it an EJB?

如果您的应用程序服务器是 JEE 兼容的(即不是 Tomcat)并且您的应用程序是 middle/big 大小并且您需要事务、可伸缩性,并且您希望 class 作为具有特定业务逻辑的独立组件,那么您可能需要一个 EJB。此外,您是否尝试过 运行 您的 classes ?因为如果它们不由容器管理,@Inject 将无法正常工作。

I become to think that it some outdated stuff for only Client-Server model with thick cliend to help making calls to the servers EJBs through remote calls and it SHOULDN'T be used in projects with web or self-running computing programs. Is that true?

不幸的是,大多数人认为 EJB 的当前规范仍然是 2.x,而 3.x 自 2009 年以来就已经过时了。他们当前规范中的 EJB 是可扩展的、事务性的...他们有很多优点多于缺点,它们非常适合网络环境。

然而,仅仅因为您提到了远程调用:@Remote 接口需要考虑一些开销并做出一些设计决策(粗粒度接口与细粒度接口)。

[更新]

关于可伸缩性,这些是官方 EJB 3.1 规范中的一些片段,还有更多:

刚刚介绍

Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure.

然后...

A typical EJB container provides a scalable runtime environment to execute a large number of session objects concurrently.