Using domain objects at view level

[juanignaciosl]

Some people say it's better not using domain objects at view layer. I saw it years ago with Struts, and debate is still open somewhere.
For example, if you have a MyDomainClass class which has a myProperty String property, some people would use {myDomainObject.myProperty} at a JSF input field. Others would create a MyDomainBean with the same properties and use it instead of the database recovered domain object. Of course they should copuy the properties twice, once when they enter the page, other at form submission.

Dozer (http://dozer.sourceforge.net) is a framework which addresses this problem, and makes mapping properties easier.

What's the suggested way to do this at Seam? I am pretty sure Seam suggests using domain object everywhere, but I don't know whether it's a must or a suggestion.
Has anybody used Dozer with Seam?

Thanks in advance!

[luxspes]

I have not used Dozer (but I have read about it). I think Seam is supposed to make easier for you to use the same object for display in the UI and to persist in to the database, but I am not completly sure that it succeds 100% in this goal.

For example, if one of your objects fails validation, JPA will force you to discard it (And its data), and re-read it from the UI. In stateless aplications that was not an issue, but here, it forces you to implement pre-validation logic to prevent your objects from being discarded.

Another issue is a somewhat magic interaction between transactions,conversations and entities that I still don't fully grasp, but I am thinking that maybe using Dozer could act as some kind of workaround (my guess is this may only be happening because we are using @Entities) instead of annotation free POJOs (maybe we need a new AFPOJOs acronym?).

Maybe Dozer could evolve to offer something like CarrierWave and better help us with this issues.