java 我应该在 DTO 中使用构建器模式吗?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/31818287/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-11-02 19:10:42  来源:igfitidea点击:

Should i use builder pattern in DTO?

javadesign-patternsdtodata-transfer-objectsbuilder-pattern

提问by jscherman

This might be a pretty subjetive question, but i would to know some more opinions. I've built a Rest API service with Spring MVC, and i implemented the DTO-Domain-Entity pattern. I want to know what do you think about implementing the Builder patternin DTOs, something like

这可能是一个相当主观的问题,但我想知道更多的意见。我用 Spring MVC 构建了一个 Rest API 服务,并实现了 DTO-Domain-Entity 模式。我想知道您对在 DTO 中实现Builder 模式有何看法,例如

public class UserResponseDTO
    extends AbstractResponseDTO {

    private String username;
    private Boolean enabled;

    public UserResponseDTO(String username, Boolean enabled) {
        this.username = username;
        this.enabled = enabled;
    }

    public String getUsername() {
        return this.username;
    }

    public Boolean getEnabled() {
        return this.enabled;
    }

    public static class Builder {

        private String username;
        private Boolean enabled;

        public void setUsername(String username) {
            this.username = username;
        }

        public void setEnabled(Boolean enabled) {
            this.enabled = enabled;
        }

        public UserResponseDTO build(){
            return new UserResponseDTO(username, enabled);
        }
    }
}

According to the definition:

根据定义:

The intent of the Builder design pattern is to separate the construction of a complex object from its representation. By doing so the same construction process can create different representations.

Builder 设计模式的目的是将复杂对象的构造与其表示分离。通过这样做,相同的构建过程可以创建不同的表示。

In most of my DTO cases (to not say all of them) i don't have a more complex object to build, such this case. And, honestly, i can't think of any example where construct a complex object if we are talking about DTOs.

在我的大多数 DTO 案例中(不是说所有案例),我没有更复杂的对象要构建,例如这种情况。而且,老实说,如果我们谈论 DTO,我想不出任何构建复杂对象的例子。

One of the patterns which helps make immutable objects easier to use and to add clarity to code is the Builder pattern.

有助于使不可变对象更易于使用并增加代码清晰度的模式之一是 Builder 模式。

Builder pattern provides objects immutabiltiy. Then, we can think than a DTOs is the service response itself and should not be altered as this is a response (at least that is how i am thinking about it)

构建器模式提供对象不变性。然后,我们可以认为 DTO 是服务响应本身,不应更改,因为这是响应(至少我是这么想的)



So what do you think? Should i use this pattern to DTOs (given the fact that this case, and probably most of them, does not satisfy the complex object principle)?

所以你怎么看?我应该将这种模式用于 DTO(考虑到这种情况,可能是大多数情况,不满足复杂对象原则)?

回答by Bobby StJacques

My short answer is that it's a matter of preference. If you like the way that Builder Pattern works, apply it. For such a small case, I don't think it matters either way. My personal preference would be not to use Builder here as it doesn't seem to add much value.

我的简短回答是,这是一个偏好问题。如果您喜欢 Builder Pattern 的工作方式,请应用它。对于这么小的案例,我认为这两种方式都不重要。我个人的偏好是不要在这里使用 Builder,因为它似乎没有增加太多价值。

My longer answer is that Builder Pattern is designed to facilitate easier configuration of complex objects without resorting to anti-patterns like telescoping constructor. In this case, you don't have an anti-pattern in either case; both options are relatively small and efficient.

我更长的答案是 Builder Pattern 旨在促进更轻​​松地配置复杂对象,而无需求助于像伸缩构造函数这样的反模式。在这种情况下,您在任何一种情况下都没有反模式;这两种选择都相对较小且有效。

While we're talking about preferences, though, I prefer a modified version of the builder pattern that uses a fluent interface; each method returns the instance of Builder so that the method calls can be chained together (rather than on separate lines). This is similar to the Java example in the article that you linked.

然而,当我们谈论偏好时,我更喜欢使用流畅界面的构建器模式的修改版本;每个方法都返回 Builder 的实例,以便方法调用可以链接在一起(而不是在单独的行上)。这类似于您链接的文章中的 Java 示例。

I'd modify your builder to look like this:

我会将您的构建器修改为如下所示:

public static class Builder {

        private String username;
        private Boolean enabled;

        public Builder setUsername(String username) {
            this.username = username;
            return this; 
        }

        public Builder setEnabled(Boolean enabled) {
            this.enabled = enabled;
            return this;
        }

        public UserResponseDTO build(){
            return new UserResponseDTO(username, enabled);
        }
    }

Thus, using the builder would look something like this:

因此,使用构建器看起来像这样:

UserResponseDTO ur = new Builder().setUsername("user").setEnabled(true).build();

Again, just a matter of personal preference.

同样,这只是个人喜好的问题。