在实体对象中创建服务层的新实例是否正确?
Is it right to create a new instance of a service layer within an entity object?
我正在编写一个应用程序,该应用程序获取一个猜测名称列表(我们称之为 entry
),然后获取一个随机名称列表 (nameList
) 并签入 nameList
有多少名字 entry
正确,然后 returns 根据结果进行 class 验证(例如 WINNER1)。这个应用程序应该能够允许执行另一种类型的游戏。每个实体对象控制名称的捕获和获得 classification(我对此不太满意,但我不允许更改它)。我创建了一个服务 class,它实现了一个通用服务 class(它有一个 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 class 中创建 NamesService 的全局实例,以便能够从其服务 class 调用 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。
您不想将 数据 与 业务逻辑 混合。在您的服务中,您将实现您的信息流在达到最终状态并准备好存储之前将经历的业务逻辑。此时你的信息将被映射到实体,也就是数据的持久化表示。
所以基本上,实体应该是关于表示一个持久化对象及其属性,可能会添加一些与这些属性的含义相关的(基本)方法,它们不应该实现复杂的业务逻辑过程。
Is this the right way to do it or is there a better way? I am trying
to follow the DDD pattern and SOLID design principles.
服务以执行处理为目标。
在 DDD 中,您不想拥有 服务 ,但您希望对象在它们之间协作以执行处理,实际上这就是您所做的。所以你走对了:你让 Names
和 NamesService
在它们之间进行协作。但请注意,您应该避免使用 service
后缀,而应该使用能够更好地表达域的名称,例如 Classification
。
Does it make a difference to create a global or local variable, or is
it wrong to instantiate 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 {...}
如果要对名称进行单元测试,还建议为依赖项提供构造函数(或 setter)。
One more thing, is it necessary to implement this using springboot?
您可以使用 Spring Boot 的原因有很多,例如受益于依赖注入、事务管理和依赖之间的一致性。 Service
和 RestController
并不是使用 Spring 和 Spring Boot 的唯一原因。
我正在编写一个应用程序,该应用程序获取一个猜测名称列表(我们称之为 entry
),然后获取一个随机名称列表 (nameList
) 并签入 nameList
有多少名字 entry
正确,然后 returns 根据结果进行 class 验证(例如 WINNER1)。这个应用程序应该能够允许执行另一种类型的游戏。每个实体对象控制名称的捕获和获得 classification(我对此不太满意,但我不允许更改它)。我创建了一个服务 class,它实现了一个通用服务 class(它有一个 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 class 中创建 NamesService 的全局实例,以便能够从其服务 class 调用 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。
您不想将 数据 与 业务逻辑 混合。在您的服务中,您将实现您的信息流在达到最终状态并准备好存储之前将经历的业务逻辑。此时你的信息将被映射到实体,也就是数据的持久化表示。
所以基本上,实体应该是关于表示一个持久化对象及其属性,可能会添加一些与这些属性的含义相关的(基本)方法,它们不应该实现复杂的业务逻辑过程。
Is this the right way to do it or is there a better way? I am trying to follow the DDD pattern and SOLID design principles.
服务以执行处理为目标。
在 DDD 中,您不想拥有 服务 ,但您希望对象在它们之间协作以执行处理,实际上这就是您所做的。所以你走对了:你让 Names
和 NamesService
在它们之间进行协作。但请注意,您应该避免使用 service
后缀,而应该使用能够更好地表达域的名称,例如 Classification
。
Does it make a difference to create a global or local variable, or is it wrong to instantiate 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 {...}
如果要对名称进行单元测试,还建议为依赖项提供构造函数(或 setter)。
One more thing, is it necessary to implement this using springboot?
您可以使用 Spring Boot 的原因有很多,例如受益于依赖注入、事务管理和依赖之间的一致性。 Service
和 RestController
并不是使用 Spring 和 Spring Boot 的唯一原因。