Pour ton erreur : j'ai un doute, mais la dernière propriété de ton persistence.xml me parait anormale. Ce devrait être :
<property name="hibernate.connection.shutdown" value="true" />
(valeur en attribut, et non comme contenu de la balise).
De manière plus générale, sur tes questions d'archi : oublie l'idée de séparer entités et objets métier. Rajoute tes annotations directement, et basta. S'il commence à y avoir trop de code métier sur tes objets et que la classe devient trop longue, tu pourras toujours le scinder en deux : faire une super-classe abstraite avec juste les données et les annotations JPA, et une classe fille (qui sera celle référencée partout dans l'appli) avec le code métier. Honnêtement, j'ai rarement ressenti le besoin de le faire. En séparant entity et objet métier dès le début, tout ce que tu gagnes c'est une méthode inutile pour copier-coller le contenu de l'une dans l'autre. C'est essentiellement un vieil héritage de l'époque des EJB Entity de J2EE 1.4 où tu n'avais pas le choix (point de détail : on JEE 5, on dit Entity, pas EJB Entity).
Pareil pour la couche de Service : est-ce qu'il y a vraiment un besoin ? Ç'a été une mode pendant longtemps, de multplier les couches superposées, et ça n'a jamais réussi à empêcher que les problématiques d'une couche remontent à celle du dessus (par contre, pour s'assurer que la moindre évolution fonctionnelle demande trois fois plus de changements, ça marche nickel).
Dernier point : ton DAO contient quoi ? Si tu utilises l'EntityManager, tu peux te contenter d'un DAO générique pour toutes tes classes pour les méthodes CRUD, et n'avoir de classes spécifiques que pour les requêtes un peu plus élaborées (recherches ou mises à jour en masse).
Bref : fais simple.
Partager