Il s'agit d'un problème courant à N+1, Qu'est-ce que SELECT N+1 ? multiplié. Pour ce qui est des performances, difficile à dire : très probablement, vous perdrez en performance. Mais peut-être pas.
Le problème est que si vous essayez d'itérer sur une collection très volumineuse, vous obtiendrez N+1 requêtes à la base de données : une pour l'ensemble de la collection, une par entité. Cela peut être bon ou mauvais, en fonction de la mise en cache et de la nature de vos données.
Mise à jour : le bon sens suggère de coder la chose la plus simple qui fonctionne (c'est-à-dire les paramètres par défaut), puis d'effectuer un profilage sous la rubrique utilisation réelle et de décider de l'approche à adopter une fois que vous disposez des données.
Il n'est pas vraiment utile de s'en tenir à une solution particulière dès le départ. Si vous n'avez besoin que d'un seul élément de la collection, c'est l'extraction rapide qui l'emportera. Peut-être. Si vous avez besoin de l'ensemble de la collection, la recherche extra-légère aura un impact sur les performances. En d'autres termes, si vous n'avez pas l'ensemble du domaine en cache, dans ce cas, vous n'avez pas à vous en soucier. En général.
En ce qui concerne l'API des critères et la déclaration explicite, cela va à l'encontre de l'objectif d'Hibernate : vous aimeriez que votre couche métier ne se préoccupe pas (aussi longtemps que cela est raisonnablement possible) des détails du mappage. Ainsi, tant que vous pouvez conserver les paramètres de mappage dans les mappages eux-mêmes, il est préférable de le faire. Comme toujours, YMMV.
