Comment modéliser en Java EE?

Question

Le mot Let, j'ai décidé d'aller avec la pile Java EE pour mon application d'entreprise.

Maintenant, pour la modélisation de domaine (ou: pour la conception du M de MVC)?, Les API que je peux assumer en toute sécurité et d'utilisation, et que je devrait rester loin de ... disons, par une couche d'abstraction

Par exemple,

1. Dois-je aller de l'avant et de la litière de mon modèle avec des appels à l'API Hibernate / JPA? Ou, devrais-je construire une abstraction ... une couche de persistance de mon propre pour éviter de coder en dur contre ces deux API de persistance spécifique? Pourquoi je demande ceci: Il y a quelques années, il y avait cette API Kodo qui a obtenu supplanté par Hibernate. Si l'on avait conçu une couche de persistance et codifiés le reste du modèle contre cette couche (au lieu de jeter des ordures le modèle avec des appels à l'API spécifique du fournisseur), il aurait permis une (relativement) passer facilement de Kodo hiberner à xyz.

2. est-il recommandé d'utiliser agressive du QL * fourni par votre fournisseur de persistance dans votre modèle de domaine? Je ne suis pas au courant des problèmes du monde réel (comme la performance, l'évolutivité, la portabilité, etc.) découlant d'une utilisation intensive d'un HQL comme la langue. Pourquoi je demande ceci:. Je voudrais éviter, autant que possible, l'écriture de code personnalisé lorsque la même chose pourrait être accompli par langage de requête qui est plus portable que SQL

Désolé, mais je suis un débutant complet dans ce domaine. Où puis-je trouver plus d'informations sur ce sujet?

Answer 1

Voici ce que je pense est la vision traditionnelle:

• Les entités de votre projet forment le modèle de domaine. Ils devraient être réutilisables et non étroitement couplée à une technologie de persistance (je reviendrai plus tard sur les couplage lâche serré contre)
• La couche d'affaires, utilise le modèle de domaine, mais expose également des services et d'autres animaux.
• La couche d'accès aux données est en charge de persister le modèle de domaine (entités) dans un magasin persistant.

Une entité ne doit pas appeler la couche d'accès aux données directement. Mais la couche d'affaires, de manière à charge et persisteront entités du modèle de domaine.

Si vous associez que les technologies Java EE vous obtenez quelque chose comme:

• Entités -> POJO avec annotations Hibernate / JPA. Notez que les annotations ne signifie pas un couplage étroit avec JPA / Hibernate, le même POJO pourrait être utilisé ailleurs sans mise en veille prolongée.
• couche Business -> Session EJB ou Spring
• couche d'accès aux données -> JPA / Hibernate

C'est une esquisse et il y a beaucoup de variantes possibles. Vous pouvez notamment ignorer l'EJB session et mettre en œuvre la couche d'affaires d'une autre manière. Vous pouvez également décider d'avoir l'appel de la couche d'affaires de l'APP / Hibernate Session / EntityManager directement, auquel cas JPA / Hibernate est vraiment le DAL, ou vous pouvez envelopper accéder à la session / EntityManager en soi-disant Data Access Objects (DAO ).

En ce qui concerne HQL, essayer de coller à ce qui est portable, et si vous utilisez SQL natif, suivez les conventions SQL-92. Si les étoffes se compliquent, peut-être introduire OTI. De cette façon, vous savez que le seul endroit où il y a des requêtes HQL est dans les OTI. Vous pouvez également d'abord mettre en œuvre la logique de requête « procédure » dans le DAO, et si vous avez des problèmes de performance, re-mettre en œuvre avec une HQL compliquée.

EDIT

En ce qui concerne vos questions dans le commentaire:

La couche d'affaires dépend de la couche de données. Si vous voulez que la couche d'affaires à ne pas dépendre Hibernate / JPA alors votre besoin de couche de données abstrait Hibernate / JPA loin. Si vous utilisez DAO pour votre couche de données, ce sera le cas. Le DAO sera la « couche mince de persistance écrite à la main sur Hibernate » (pour prendre vos mots). J'introduirais DAO pour toutes les entités dans votre cas.

Qu'est-ce que vous demandent est une question de conception assez générique. Je ne peux pas donner une recette définitive pour cela, ni résumer peut-être toutes les variantes dans une réponse car elle dépend au cas par cas. Par exemple, on n'a pas parlé à ce jour sur le problème des transactions, que vous commencez généralement dans la couche d'affaires, mais que la couche de données doit être au courant. Cela dépend généralement des technologies utilisées et vos besoins.

Pourtant, voici une liste des ressources que vous pourriez être intéressé par: les livres Motif de l'Entreprise Application Architecture , le livre Real World Java EE modèles - Repenser les meilleures pratiques , le livre domaine Driven design et plus particulièrement les modèles Data Access Object , pattern Repository , Open session in View (si elle est pour une application web ), Et peut-être Anemic modèle de domaine.

EDIT 2

Ok, quelques phrases surtransactions:

Les transactions devrait théoriquement être gérée dans la couche d'affaires; la définition de ce qui doit être fait dans une unité de travail à être cohérent dépend en effet de la logique même de l'application.

Avec EJB3, les transactions peuvent être déclarées avec annotations et l'application. serveur gère pour vous. Voir cette autre réponse de mes pour plus d'informations. Avec le printemps, vous pouvez également marquer les transactions déclarative, mais je ne connais pas les détails. Sinon, vous devrez démarrer / arrêter la transaction vous. Ce sera un peu différent si vous utilisez des transactions JDBC ou transactions JTA.

Transactions concerne également le chargement paresseux dans Hibernate / JPA. Une entité qui était chargée paresseux, peut en effet être chargé que s'il y a une transaction en cours. Si les opérations sont terminées dans la couche d'affaires, les entités qui sont retournées à la couche de présentation ont besoin d'être avec impatience chargés.

Pour contourner ce problème, un modèle populaire pour les applications web est Open Session in View , qui je l'ai déjà mentionné. Dans ce cas, la couche de présentation de démarrage / arrêt des opérations (ce qui est un peu mal sur le plan conceptuel), mais fonctionne très bien avec le chargement paresseux.

Answer 2

Votre modèle de domaine et sa couche de persistance devrait en théorie être séparés - il n'y a pas besoin d'une classe appelée Entity rien savoir si et comment il est persisté, de sorte que vous pouvez utiliser quelque chose comme Hibernate pour créer la couche de persistance sans polluer la classes de modèle de domaine eux-mêmes. Vous faites « le code du modèle [...] contre cette couche » pas - vous codez le modèle, la carte puis à un magasin persistant avec une sorte de couche ORM, où le modèle de domaine ne dépend pas de la couche ORM. Il est évident que la couche de persistance dépendra du modèle de domaine, mais c'est très bien.

Je me bats personnellement timide d'utiliser trop HQL avec (N) Hibernate pour la raison que vous demandez, mais il y a des moments où il est inévitable. Vous savez déjà, et avez vous-même souligné, le principal problème là, donc vous ne pas abuser de toute façon.