Our application uses Spring, Hibernate and Wicket with a traditional
service facade architecture and I think it's a good choice for medium
to large code bases (although possibly overkill for smaller
projects). The service facades provide a convenient place to define
transactionality and they keep most of the business logic out of the
UI. Having said that, there's nothing wrong with injecting DAO's into
your Wicket components and skipping the service facade, but the lack
of that tier may be a problem as your code base grows. Here are a few
implementation details that might help you get things up and running:
1) We use Wicket's Spring annotation support (http://www.wicket-
wiki.org.uk/wiki/index.php/Spring#Annotation-based_Approach) to
inject facade beans into pages and components, like so:
@SpringBean
private MyServiceBean myServiceBean;
The initial configuration is slightly tricky, but only because wicket-
spring offers several completely different approaches to injecting
beans.
2) About the only specific support for Hibernate (although it's
easily adaptable to any ORM) in our Wicket classes is the fairly
heavy use of this model (comments and equals/hashcode removed for
clarity):
public class EntityModel extends LoadableDetachableModel {
private final Class<?> clazz;
private final Serializable id;
public EntityModel(Persistable object) {
this( Hibernate.getClass( object ), object.getId(), object );
}
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 );
}
@Override
public int hashCode() {
// Hash code based on clazz and id.
...
}
@Override
public boolean equals(Object obj) {
// Equals based on clazz and id.
...
}
}
That first, very convenient constructor is made possible because all
of our persistable domain objects implement a Persistable interface
that defines the getId() method -- you might want to consider
something similar. Note the use of Hibernate.getClass() in that
constructor, which makes it safe to pass in a Hibernate proxy.
3) The only other Hibernate-specific code we have in our Wicket
classes is something along the lines of
'HibernateSessionLocator.getSession().get(...)' to retrieve domain
objects. We use backing beans in our forms and so we often need to
fetch domain objects based on a primary key stored in a bean. You
could of course use a DAO or service facade method to keep this kind
of thing nicely abstracted away from your Wicket code.
btw, we're using Wicket 1.2, but I think everything mentioned here
applies equally to 1.3.
hth,
-Ryan
On Aug 12, 2007, at 12:15 PM, Mathias P.W Nilsson wrote:
Hi all!
I'm in a aqward situation and thinking of swithing from Struts2,
JSTL, Tiles
to Wicket. I've bought the book Pro Wicket and read 4 chapters. The
book is
very good but I need a real life application tutorial.
My application today integrates with Hibernate. I shouldn't call
the DAO it
the WebPage classes should I?
How about Session Facade pattern and Wicket. How is this done in a
real
world application?
Very thankful for replies!
// Mathias
--
View this message in context: http://www.nabble.com/Real-example-on-
Wicket-tf4257796.html#a12116996
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
