Quand utiliser Hibernate / JPA / Toplink?

StackOverflow https://stackoverflow.com/questions/122571

Question

Actuellement, je crée un site Web extrêmement simple d'environ 5 pages. La question est de savoir si c'est excessif et vaut la peine d'intégrer une sorte de solution de mappage de base de données ou s'il serait préférable d'utiliser simplement du vieux JNDI. J'aurai peut-être une douzaine de choses à lire / écrire dans la base de données. Je suppose que j'ai une compréhension de base de ces technologies, mais il faudrait quand même beaucoup se référer à la documentation. Quelqu'un d'autre a-t-il déjà été confronté à la décision?

EDIT: Désolé, j'aurais dû spécifier à JNDI de rechercher la connexion à la base de données et à JDBC d'effectuer les opérations.

Était-ce utile?

La solution

Réponse courte: Cela dépend de la complexité que vous souhaitez gérer.

Réponse longue:

Tout d’abord, ORM (mapping relationnel objet - le mapping de base de données comme vous l’appelez -) et JNDI (interfaces de dénomination et de répertoire Java) sont deux choses différentes.

Le premier, comme vous le savez déjà, est utilisé pour mapper les tables de la base de données aux classes et aux objets. La seconde consiste à fournir un mécanisme de recherche des ressources, qu’il s’agisse de sources de données, d’ejb, de files d’attente ou autres.

Peut-être que votre moyenne "JDBC" signifie.

Maintenant, pour ce qui est de votre question: si c’est aussi simple, il ne serait peut-être pas nécessaire de mettre en œuvre un ORM. Les tables de nombres seraient au maximum de 5 à 10, et les opérations très simples, je suppose.

Il serait probablement suffisant d'utiliser JDBC en clair.

Si vous utilisez le modèle DAO, vous pourrez le modifier ultérieurement pour prendre en charge la stratégie ORM si nécessaire.

Comme ceci: Disons que vous avez la table des employés

Vous créez le fichier Employee.java avec tous les champs de la base de données à la main (cela ne devrait pas prendre trop de temps) et un EmployeeDaO.java avec des méthodes telles que: 

+findById( id ): Employee
+insert( Employee ) 
+update( Employee )
+delete( Employee ) 
+findAll():List<Employee>

Et la mise en œuvre est assez simple: 

select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc

Lorsque (et si) votre application devient trop complexe, vous pouvez modifier la mise en œuvre de DAO. Par exemple, dans la section "Sélectionner". Si vous modifiez le code pour utiliser l’objet ORM qui effectue l’opération. 

public Employee selectById( int id ) {
      // Commenting out the previous implementation...
      // String query = select * from employee where id = ? 
      // execute( query )  

      // Using the ORM solution

       Session session = getSession();
       Employee e = ( Employee ) session.get( Employee.clas, id );
       return e;
}

Ce n’est qu’un exemple. Dans la vie réelle, vous pouvez laisser l’usine d’abstraits créer le DAO ORM, mais c’est hors sujet. Le fait est que vous pouvez commencer simplement et en utilisant les modèles de dessin, vous pouvez modifier l’implémentation ultérieurement si nécessaire.

Bien sûr, si vous souhaitez apprendre la technologie, vous pouvez commencer avec 1 table.

Le choix de l’une ou l’autre solution (ORM) dépend essentiellement de la technologie que vous utilisez. Par exemple, pour JBoss ou d'autres produits opensource, Hibernate est excellent. Il est opensource, il y a beaucoup de ressources sur lesquelles apprendre. Mais si vous utilisez quelque chose qui a déjà Toplink (comme le serveur d’applications Oracle) ou si la base est déjà construite sur Toplink, vous devriez rester avec ce framework.

En passant, depuis que Oracle a acheté BEA, ils ont annoncé qu’ils remplaceraient Kodo (weblogic peresistence framework) par toplink dans le désormais "Oracle Weblogic Application Server".

Je vous laisse des ressources où vous pouvez obtenir plus d'informations à ce sujet:

Dans cette section "Modèles d'architecture d'application d'entreprise" livre, Martin Fowler, explique où utiliser l’un ou l’autre, voici le catalogue. Examinez les modèles architecturaux de source de données par rapport aux modèles comportementaux relationnels-objet:

catalogue PEAA

DAO (Data Access Object) fait partie du catalogue de modèles J2EE principal:

Le modèle DAO

Ceci est un didacticiel de démarrage pour Hibernate:

Hibernate

La page officielle de Toplink:

Lien principal

Enfin, je "pense" La bonne pensée de JPA est que vous pouvez changer de fournisseur récemment.

Commencez simple puis évoluez.

J'espère que cela vous aidera.

Autres conseils

Il semble qu’il serait excessif de créer une application très simple, surtout si vous n’avez pas l’intention de la développer davantage. Cependant, il semble également utile d’utiliser celles-ci avec cette application simple pour mieux comprendre leur fonctionnement pour la prochaine fois que vous avez quelque chose qui pourrait les utiliser.

Voulez-vous dire tout simplement JDBC? Un petit projet pourrait être une bonne occasion de choisir l’un des cadres ORM, surtout si vous avez le temps.

Sans plus d'informations, il est toutefois difficile de formuler une recommandation d'une manière ou d'une autre.

Ma règle générale est que si elle est en lecture seule, je suis prêt à le faire dans JDBC, bien que je préfère utiliser un projet Hibernate vide avec SQLQuery pour tirer parti du mappage de types d'Hibernate. Une fois que je dois faire des écritures, je pars avec Hibernate car il est tellement plus facile de définir quelques attributs, puis d’appeler save que de définir chaque colonne individuellement. Et lorsque vous devez commencer à optimiser pour éviter les mises à jour sur des objets inchangés, vous êtes bien mieux avec un OR / M et sa vérification incorrecte. Traiter avec les relations de clé étrangère est un autre signe que vous devez mapper une fois puis utiliser les accesseurs. La même logique s’appliquerait à Toplink, bien qu’à moins d’ajouter quelque chose comme HQL au cours des trois dernières années, Hibernate serait bien mieux pour ce type de transition depuis le SQL pur. N'oubliez pas qu'il n'est pas nécessaire de mapper chaque objet / tableau, mais uniquement ceux pour lesquels il existe un net avantage. D'après mon expérience, la plupart des projets qui n'utilisent pas un OR / M existant finissent par en construire un nouveau, ce qui est une mauvaise idée.

La meilleure méthode d’apprentissage ORM consiste à réaliser un petit projet. Commencez ce projet.

Une fois que vous avez compris, vous utiliserez ORM pour tout.

Rien n’est trop petit pour ORM. Après vos deux premiers projets, vous constaterez que vous ne pouvez pas travailler autrement. Le mappage ORM est généralement plus logique que presque toute autre méthode de travail.

Regardez les différents guides de liens supérieurs ici, ils ont une introduction, des exemples, des scénarios, etc.

http://docs.oracle.com/cd/ E14571_01 / web.1111 / b32441 / toc.htm

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top