Working with DTO - jsf

Question

When I working with a DTO inside a ManagedBean, should I encapsulate the getters and setters?
class UserMBean {
private UserDTO user;
public String getName() {
return user.getName();
}
public void setName(String name) {
user.setName(name);
}
}
Or access directly the parametters from JSF:
<h:outputText value=#{userMBean.user.name} />

Answer 1

In general, people tend to use such encapsulation to hide the specific implementation of services or the structure of the model. It's an abstraction in order to make your code easier to modify without having to change the code on other places as well.
If you "flatten" your model this way, you actually just shift the knowledge of how your model looks like from the facelets to the managed bean. If you change your model now, you need to change the javacode instead of the xhtml code. One benefit in this scenario is that you now have a compile time error instead of runtime. On the other hand you kind of introduced duplicated code. Since your model is probably likely to change less often compared to service implementations, I usually "deeply" access my models in the xhtml code, because it saves time and is just more comfortable and keeps the managed beans more clean. In your simple case I would avoid the additional getter.
It is, as so often, a matter of taste and usecase specific. If you "deeply" access a property of your model through five (model) layers, and you do this in ten different places and you know that your model structure might change soon, it starts to make more sense to have a utility method to directly access this property with an additional getter in one place in a managed bean.
However there is one more case where it is necessary to offer direct access to properties. If you want to avoid someone accessing other properties. That means, you want to keep certain attributes non-accessible. Let's say your UserDTO also a property password and you don't want anyone to be able access that in your xhtml to display or change it, then roll with your second option and don't have a getUser(), but offer direct access to the username via getUserName().