@瞬态vs装饰器
@瞬态vs装饰器
提问于 2017-02-14 10:59:31
我在塑造我的实体时有点矛盾。
我们有一个实体，大约有6-8个实例变量。其中两个实际上并不是持久化在数据库中，而是只用于进行某些验证或在UI中显示。因此，当我们获取实体时，我们填充了一些外部查找。
现在，据我的一位同事说，它的更好的实践使用装饰，而不是使用@瞬态。在某种程度上我同意。因为它澄清了DB所代表的实际模型。
但它会在某些情况下增加额外的样板(例如，对于业务，我可以将实体命名为MyEntityBO )。但是，如果我将它用于UI...again，名称将有点混乱。
我的问题是，哪种情况比使用“临时”比使用“装饰师”更好?反之亦然。
回答 2
Stack Overflow用户
回答已采纳
发布于 2017-02-14 22:12:12
将实体同时用于DB映射和UI映射并不是一个很好的实践。总要考虑单一责任原则。实体应该只负责DB映射，不再负责。您应该为UI表示创建DTO层。但是在这种情况下，您也应该创建转换器，这很无聊，我建议使用Mapstruct - http://mapstruct.org。如果你不得不使用@瞬态--这是第一个错误的征兆，记住它。祝你好运:)
@Entity
public class User {
@Id
Long id;
String name;
}
public class UserDto{
Long id;
String name;
}
public class UserConverter{
public UserDto toDto(User user) {
if (user == null) return null;
UserDto dto = new UserDto();
dto.setId(user.getId());
dto.setName(user.getName());
return dto;
}
public User toEntity(UserDto dto){...}
}在DTO对象中，您可以为某些目的创建所需的附加字段或方法。
Stack Overflow用户
发布于 2017-02-14 11:16:32
使用Decorator模式的主要缺点是代码维护可能是一个问题(根据我的经验)。我强烈建议你使用“暂时性”。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/42224415
复制相关文章
相似问题
腾讯云开发者
