web-dev-qa-db-fra.com

Hibernate ou JPA ou JDBC ou?

Je développe une Java Desktop Application mais j'ai quelques confusions dans le choix d'une technologie pour ma couche de persistance.

Jusqu'à présent, j'utilisais JDBC pour les opérations DB. Maintenant, récemment, j'ai appris Hibernate et JPA, mais je suis toujours novice sur ces technologies.

Maintenant, ma question est quoi utiliser pour mon Java Desktop Application parmi les suivantes?

  • JPA

  • Hibernate

  • JDBC

  • DAO

  • toute autre suggestion de votre part ...

Je sais qu'il n'y a pas de meilleur choix de leur part et cela dépend totalement de la complexité et des exigences du projet donc voici les exigences de mon projet

  1. Ce n'est pas une application complexe. Il ne contient que 5 tables (et 5 entités)
  2. Je ne veux pas rendre mon code flexible pour pouvoir changer la base de données plus tard facilement
  3. La taille de l'application doit rester aussi petite que possible car je devrai la distribuer à mes clients via internet.
  4. Il doit être libre d'utilisation dans le développement commercial et la distribution.

==================================== EDITED ============= ==========================

Sur la base des réponses ci-dessous, je voudrais aller avec JPA afin de m'empêcher d'écrire du code SQL spécifique au fournisseur.

Mais j'ai des problèmes dans JPA qui sont mentionnés à Java Persistence API

javahibernatejpajdbcdao
34
Yatendra Goel

Voici mon point de vue:

  • JPA: façon agnostique de faire Java persistance sans coupler vos clients à Hibernate, TopLink, etc.
  • Hibernation: bon choix si vous avez un modèle d'objet à mapper.
  • JDBC: Tous Java la persistance est construite sur cela. Niveau le plus bas
  • DAO: Plus d'un modèle qu'une technologie; Interface d'opération CRUD.
  • iBatis: à mi-chemin entre JDBC (SQL brut) et Hibernate (ORM).
  • JDO: Java Data Objects, qui est une autre spécification pour Java persistence. (Par exemple, Apache JDO )

Ce n'est pas une application complexe. Il ne contient que 5 tables (et 5 entités)

Tout cela fonctionnera, mais JDBC sera le plus simple. Tous les autres sont construits au-dessus de JDBC.

Je veux rendre mon code flexible afin de pouvoir changer la base de données plus tard facilement

Les modifications de schéma auront des effets similaires dans toutes les technologies.

La taille de l'application doit rester aussi petite que possible car je devrai la distribuer à mes clients via internet.

L'utilisation de JPA ou d'Hibernate nécessitera des fichiers JAR qui augmenteront la taille de votre déploiement. JDBC minimisera cela.

Il doit être libre d'utilisation dans le développement commercial et la distribution.

Voir les licences de toutes les technologies. Cela ne devrait pas être un problème avec aucun d'entre eux.

FYI: Il est possible d'écrire une interface DAO générique:

package persistence;

import Java.io.Serializable;
import Java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);
    List<T> find(String queryName, String [] paramNames, Object [] bindValues);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

Si vos objets mappent 1: 1 avec vos cinq tables, je dirais que JPA est trop carré.

Votre application est-elle actuellement de l'ordre de 3MB JAR? Si non, Hibernate ou JPA doublera de plus de la taille. Vous pouvez quantifier exactement combien. Et il existe plusieurs fichiers JAR, car ils ont tous deux des dépendances.

YAGNI dit que vous devriez rester simple. C'est cinq tables!

Changer de fournisseur, si vous le faites correctement, signifie changer de JAR de pilote JDBC, changer le nom de la classe de pilote et ajouter la nouvelle URL de connexion - ce que vous devez faire quelle que soit la technologie que vous choisissez.

Je trouve que les bases de données ne changent pas radicalement. Vous allez changer le schéma, mais tout le fournisseur? Peu probable, surtout si vous avez plusieurs clients. Ce sera un inconvénient majeur de créer une base de données de commutateurs de base d'utilisateurs.

Avec lequel envisagiez-vous d'expédier? HSQL ou quelque chose qui nécessitera une installation comme MySQL? C'est une préoccupation plus pertinente.

54
duffymo

JPA est certainement le chemin à parcourir si vous souhaitez utiliser le mappage de relation d'objet - il est indépendant de l'implémentation (ce qui signifie que vous pouvez l'utiliser avec Hibernate, Toplink, etc.) et c'est la norme de facto. Hibernate a un ensemble de fonctionnalités plus riche, mais c'est une solution non standard - beaucoup de gens l'utilisent cependant ... Personnellement, j'utilise toujours JPA soutenu par Hibernate. J'essaie de m'éloigner des trucs spécifiques d'hibernation, mais si besoin - c'est là pour moi.

L'utilisation d'un framework tel que JPA/Hibernate pour 5 tables peut cependant être un peu exagéré. Votre application sera environ 5 Mo plus grande et consommera plus de mémoire. Vous pouvez simplement choisir d'utiliser JDBC associé à DAO.

Étant donné que JDBC utilise SQL qui est spécifique au fournisseur (base de données), cela peut être problématique si vous prévoyez d'utiliser différentes bases de données. JPA a un net avantage dans ce domaine.

Quoi que vous choisissiez, vous ne pouvez pas vous tromper - vous devez vous demander principalement si l'augmentation de la taille et de la consommation de mémoire est un problème et êtes-vous prêt à écrire du code passe-partout DAO JDBC. Je déteste généralement ça :-)

9
Bozhidar Batsov

Pour cette échelle, tout fonctionnera bien. Considérez également iBatis .

2
lexicore