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

Question

我有以下类(class):

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);
    }
}

ServiceOne 和 ServiceTwo 是 @Stateless 注解的 EJB。

我知道容器为无状态 EJB 创建池，并且还为注入(inject)等创建代理。那么就我而言，在 ScoringService 和 DecisionHandler 的两个实例中是否可能有两个不同的 ServiceOne 实例？因此会出现过量生成的 ServiceOne 实例吗？我的意思是，注入(inject)了 DecisionHandler 的 ScoringService 将被调用用于一个目的，并且不需要两个持有 ServiceOne 的两个实例。

我将 DecisionHandler 设为一个单独的类，以分解集中在一个 ServiceClass 中的复杂逻辑。我还可以将决策处理程序作为一个带有方法的普通类，并在调用期间实例化它。我应该如何理解应该将其设为 EJB？

我开始认为，对于仅具有厚客户端的客户端-服务器模型来说，它是一些过时的东西，可以帮助通过远程调用来调用服务器 EJB，并且它不应该在具有 Web 或自运行计算程序的项目中使用。这是真的吗？

Answer 1

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)并且您的应用程序是中/大型并且您需要事务、可伸缩性，并且您希望一个类充当具有特定业务逻辑的独立组件，那么您可能需要一个EJB。另外，你有尝试过上课吗？因为如果它们不受容器管理，则 @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 接口(interface)就需要考虑一些开销并做出一些设计决策(粗粒度与细粒度接口(interface))。

[更新]

关于可扩展性，这些只是官方 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.