Aujourd'hui, je vous présente une architecture permettant d'obtenir des modèles Wicket totalement génériques s'appuyant de manière transparente sur des DAO Hibernate.

Cette intégration "back to front", s'appuyant sur les types génériques Java, couvre 80% des cas d'utilisation standard des modèles Wicket et permet de simplifier le code des pages.

Analyse du besoin

Dans la plupart des cas, nos modèles Wicket remplissent l'une des 3 fonctions suivantes :

• Récupérer une entité métier par son ID
• Récupérer une liste d'entités métiers, optionnellement triée (pour affichage simple)
• Récupérer une liste d'entités métiers, optionnellement triée et/ou paginée (pour les DataTable)

Nous avons vu dans de précédents billets les bases du WicketTester et comment intégrer Spring et Wicket. Nous allons pousser l'étude du WicketTester pour voir comment tester une application Wicket qui utilise Spring pour accéder à ces données. Nous verrons aussi comment utiliser des mock objects avec Mockito pour ne pas dépendre d'une véritable couche d'accès au données dans nos tests.

Spring est un framework d'injection de dépendances qui permet d'assembler les composants de votre application (services, objets d'accès aux données, etc.). Il propose aussi un support pour l'accès aux données (support JDBC, intégration avec Hibernate/JPA, gestion des transactions). Spring est donc une solution intéressante pour les parties "basses" d'une application Wicket. Wicket et Spring s'intégre très bien et ce billet vise à montrer comment mettre en place cette intégration.