Il y a plusieurs côtés à ce débat (et c'est un débat). Tout d'abord, il y a une vision répandue dans les cercles de développement de logiciels Java selon laquelle les logiciels doivent être hautement straté- 5 gés. Cela signifie souvent retirer des objets de domaine et les traduire en objets de présentation. Il peut aller encore plus loin et avoir des objets de service et d'autres entre les deux.
Cela finit souvent par être un lot de copropriétés à copier pour des raisons douteuses. Une question à vous poser est la suivante: les objets qui sortent d'Ibatis peuvent-ils être présentés? Ou sont-ils génériques dans le sens où vous, par exemple, avez une classe par table? Une application Java légère a tout à fait le droit de choisir une approche par laquelle Ibatis exécutera des requêtes qui renverront les informations exactes dont la couche de vue a besoin et qui la transmettront tout le long (ce qui ne sera pas loin). Maintenant, cela a des problèmes d'évolutivité sur les grandes applications. Vous pourriez vous retrouver avec des centaines voire des milliers de ces choses, alors dans ces situations, vous pourriez avoir besoin d'une approche différente. Là encore, dans ces situations, vous finirez probablement avec des milliers d'objets de présentation à la place. Robbing Peter pour payer Paul?
Personnellement, je désapprouve l'approche d'une classe par table chez Ibatis. Ce n'est pas sa force. C'est la force d'Hibernate et de JPA. La force d'Ibatis est qu'il peut facilement extraire n'importe quoi ainsi que n'importe quelle requête SQL (parce que c'est juste SQL). Utilisez-le de cette façon, sauf si cela crée des problèmes pour vous.