它是不好的做法，在DTO

@JsonRootName(value = "studentInfo") 
@JsonInclude(value = Include.NON_EMPTY) 
public class StudentInfo { 
    private String student; 
    @JsonProperty("address") 
    private String address; 

    @JsonProperty("studentName") 
    public String getStudent() { 
     return student; 
    } 

    @JsonProperty("studentUserId") 
    public void setStudent(String student) { 
     this.student = student; 
    } 
    public String getAddress() { 
     return address; 
    } 

    public void setAddress(String address) { 
     this.address = address; 
    } 
}

使用相同的变量有两个目的，这是我的Student类，我用我的学生相关的API为DTO这个对象。这里我使用了学生字符串变量，当调用POST/PUT/ API并传递studentUserId时，它将设置为学生字符串变量，但每当StudentInfo对象返回为响应实体时，它将返回实际名称存储在用户表中的学生。它是不好的做法，在DTO

我只是想知道，我使用学生字符串变量和@JsonProperty的方式，是正确的使用方式还是错误的做法？

来源

2016-10-28 GajanaN Chalke

是的，这是不好的做法。你应该在你的课堂中有一个单独的'userId'字段。对不同的数据使用相同的字段只是等待发生的错误。当其他人晚些时候看课程时，这也会令人困惑。 – marstran

如果字段的语义取决于使用的上下文，那么为该类编写测试也是一场噩梦。 – Fildor

不仅为一个DTO但对于所有类，程序和语言规则（基本上是真实的非学术生活），编程时，每个变量和属性都有它自己的目的，只为这使用。

如果按照这个规则，你也将遵循有关约定：

命名（每个变量都会有一个decriptive和独特的名称）
可读性（不仅是你，还有别人呢查看并了解每个变量是如何使用的）
Maintanability（当发生变化时和是，它会变化 -，你不会需要划分或使uglies解决方法做出改变或解决问题）
可测性是自己写的类测试的噩梦，如果一个字段的语义取决于（@Fildor）

和其他一些。无论如何，这只是惯例而不是强制性规则，语法会令人困惑，但是正确，因此您可以使用它。我的建议是：不要！;)

来源

2016-10-28 10:27:31

我想将可测性添加到该列表。 – Fildor

@Fildor补充说......谢谢！ –

你说得对。不是不可能的，但非常丑陋和复杂。鉴于问题中的情景：我必须编写测试，以便考虑上下文（用作响应/用作查询）。当然，有人可能会说这个领域只是因为它包含了我给它的实际价值而进行了测试，但可能还有更多。所以我在一般基础上发言。一个更好的例子是一个带边界的数字场。基于上下文，它可能有不同的有效边界，必须考虑上下文来进行测试。为了一个丑陋的不稳定测试...至少在我的愚见中。 – Fildor

它是不好的做法，在DTO

回答

相关问题