I know I wasn't asked ;) but we had to revisit this question recently
in converting a Tapestry app over to Wicket. We started off trying to
use Hibernate objects directly for the usual reasons (avoid code
duplication, more elegant, etc.) but ran into a few problems.
A small but important problem was that we had to alter domain objects
in less than ideal ways to account for the fact than any setter could
be called at any time. This meant making some private setters public
and adding redundant validation and logic that would normally go into
a dedicated, multi-parameter "update..." method meant for public use.
The biggest problems were related to transaction rollbacks after save
()-ing or reattaching Hibernate objects. Once you save a new object,
Hibernate marks it as persistent but, if it didn't actually get
committed to the database because your transaction rolled back, it's
in an invalid state and Hibernate won't let you reattach it.
Similarly, if you reattach an edited object and then the transaction
rolls back, that object will be invalid. To solve this, we ended up
reloading or recreating domain objects after transaction rollbacks
and copying user-supplied values from the old object to the new one.
Needless to say, that code looks a lot like what you have to do with
form beans, except uglier.
We avoided lazy load issues and transaction scope problems by using a
read-only session per view and transactional service methods (a
pretty standard architecture). Those parts worked fine.
In the end we decided to go with form beans only because it ends up
being a little simpler, keeps UI and domain needs separated and was
actually slightly less code if you don't count the auto-created
getters and setters on the form beans.
I still think using Hibernate objects directly can be a nice way to
go, and if you don't mind the inconsistency you might find that some
forms can do that while others use beans.
These model classes (based on an old post of Igor's) helped me
immensely with Wicket/Hibernate integration. We still use them to
back our DataTables and most of our view pages (which use Hibernate
objects directly). The first is a superclass for any Hibernate
entity. The second is an example subclass for use with a domain
supertype.
public class EntityModel extends LoadableDetachableModel {
private final Class clazz;
private final Serializable id;
public EntityModel(Class clazz, Serializable id) {
this.clazz = clazz;
this.id = id;
}
public EntityModel(Class clazz, Serializable id, Object object) {
super( object );
this.clazz = clazz;
this.id = id;
}
@Override
protected Object load() {
return HibernateSessionLocator.getSession().get( this.clazz,
this.id );
}
}
public class DomainSupertypeModel extends EntityModel {
public DomainSupertypeModel(DomainSupertype object) {
super( object.getClass(), object.getId(), object );
}
// If the object is a proxy, its runtime type might not be the actual
// persistent class, so sometimes you need to specify it.
public DomainSupertypeModel(DomainSupertype object, Class clazz) {
super( clazz, object.getId(), object );
}
}
hth,
-Ryan
On Mar 20, 2007, at 9:51 AM, ZedroS Schwart wrote:
> That's was a really instructive post, thanks Eelco.
>
> In fact I'm actually struggling with this kind of issue. I've model
> objects and then on my presentation layer the data are quite often a
> bit different, and thus I wonder which way is the best.
>
> Igor had spoken about "form beans", but then I've to map them
> somewhere with my actual domain objects, which can be quite annoying.
> Merge and VO object may be a good way to avoid some part of this pain.
>
> However, you said you weren't a fan of this pattern, could you please
> explain which approach you use ? I would really like it because I find
> it really important for ease of development and maintainability. And
> up to now I've found a way which fully pleases me.
>
> Thanks in advance
> ZedroS
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
