Jsf 与DTO合作

在ManagedBean中使用DTO时，是否应该封装getter和setter

class UserMBean {
    private UserDTO user;
    public String getName() {
        return user.getName();
    }
    public void setName(String name) {
        user.setName(name);
    }
}

或者直接从JSF访问参数：

<h:outputText value=#{userMBean.user.name} />

---

一般来说，人们倾向于使用这种封装来隐藏服务的具体实现或模型的结构。它是一种抽象，目的是使您的代码更易于修改，而不必在其他地方更改代码

如果您以这种方式“展平”您的模型，实际上您只需将模型外观的知识从facelets转移到托管bean。如果现在更改模型，则需要更改Java代码而不是xhtml代码。这种情况下的一个好处是，您现在有一个编译时错误，而不是运行时错误。另一方面，您引入了一些重复的代码。由于与服务实现相比，您的模型可能不会经常更改，因此我通常在xhtml代码中“深入”访问我的模型，因为这样可以节省时间，更舒适，并且使托管bean更干净。在你的简单情况下，我会避免额外的getter

这通常是一个口味和用例特定的问题。如果您通过五个（模型）层“深入”访问模型的属性，并且您在十个不同的位置执行此操作，并且您知道您的模型结构可能很快会发生更改，那么在托管bean中的一个位置使用一个实用方法直接访问此属性就变得更有意义了

---

然而，还有一种情况需要提供直接访问物业的服务。如果您想避免有人访问其他属性。这意味着，您希望保持某些属性不可访问。假设您的

UserDTO

也是一个属性

password

，您不希望任何人能够在xhtml中访问该属性来显示或更改它，然后使用第二个选项，并且没有

getUser（）

，而是通过

getUserName（）

提供对用户名的直接访问，你认为呢？复制/展平模型属性的具体好处是什么？我认为第二个选项是最好的，但似乎最坏的用途是调用我的“域”之外的另一个方法，即我的托管bean。看起来最糟糕的是破坏了封装。在你的域之外？为什么呢托管bean只是这里的控制器。DTO就是模型。Facelet页面就是视图。完全有道理。我仍然没有看到在控制器中复制/展平所有模型属性的任何有效理由。