在实体对象中创建服务层的新实例是否正确？答案

【问题标题】：Is it right to create a new instance of a service layer within an entity object?在实体对象中创建服务层的新实例是否正确？
【发布时间】：2018-07-16 19:05:13
【问题描述】：

我正在编写一个应用程序，它获取一个猜测名称列表（我们称之为entry），然后获取一个随机名称列表（nameList）并检查nameList 有多少个名称entry对，然后根据结果返回一个分类（例如 WINNER1）。这个应用程序应该能够允许执行另一种类型的游戏。每个实体对象都控制名称的捕获和分类（我对此不太满意，但我不允许更改它）。我创建了一个服务类，它实现了一个通用服务类（它有一个 getClassification 方法），如下所示..

public class NamesService implements GenericService {

    public String getClassification(String[] entry, String[] nameList) {
        // detailed implementation of getClassification for Names.java
        }
}

所以 Names.java 将创建一个调用 NamesService.java 的 getClassification 方法。我必须在 Names.java 类中创建 NamesService 的全局实例，以便能够从其服务类调用 getClassification。是创建全局变量还是局部变量有区别，还是实例化NamesService有问题？

public class Names {

    NamesService service = new NamesService();

    // define other attributes and behaviours

    public String getClassification(String[] entry, String[] nameList) {
        service.getClassification(entry, nameList);
    }
}

我这样写是因为我希望另一个游戏，比如 Numbers.java，能够通过使用 NumbersService 来实现 GenericService 来提供它自己的 getClassification 实现。

这是正确的方法还是有更好的方法？我正在尝试遵循 DDD 模式和 SOLID 设计原则。

还有一点，有必要用springboot来实现吗？我没有创建任何rest接口，所以我不确定是否需要springboot。

【问题讨论】：

标签： java spring-boot domain-driven-design solid-principles

【解决方案1】：

这是正确的方法还是有更好的方法？我在尝试遵循 DDD 模式和 SOLID 设计原则。

服务的目标是执行处理。
在 DDD 中，您不想拥有服务，但您希望对象在它们之间协作以执行处理，实际上这就是您所做的。所以你走对了：你让Names 和NamesService 在他们之间进行协作。但请注意，您应该避免使用service 后缀，而是使用更能传达域的名称，例如Classification。

创建全局变量或局部变量有区别吗？实例化 NamesService 有错吗？

如果你想在其他地方重用NamesService，依赖注入更好，例如：

public class Names {

    private NamesService service;
    // automatically injected with Spring
    public Names(NamesService service){
       this.service = service;
    }
    ...
}

@Component
public class NamesService implements GenericService {...}

如果您想对名称进行单元测试，还建议为依赖项提供构造函数（或设置器）。

还有一点，有必要用springboot来实现吗？

你可以使用 Spring Boot 的原因有很多，比如依赖注入、事务管理、依赖之间的一致性。 Service 和 RestController 并不是使用 Spring 和 Spring Boot 的唯一原因。

【讨论】：

这非常有用！太感谢了！将重命名服务类并添加依赖注入。非常感谢您的帮助
@joyidahosa 如果能帮到你就太好了:)

【解决方案2】：

您不想将数据与 业务逻辑 混在一起。在您的服务中，您将实现信息流在达到其最终状态并准备好存储之前将通过的业务逻辑。此时您的信息将被映射到实体，也就是数据的持久表示。

所以基本上，实体应该是关于表示一个持久化对象及其属性，可能会添加一些与这些属性的含义相关的（基本）方法，并且它们不应该实现复杂的业务逻辑流程。

【讨论】：