BDD dans un logiciel

Bonjour,

Je travaille actuellement sur un logiciel de généalogie ou il faudrait que je puisse enregistrer des personnes, des unions, des attributs et des événements. Il est intéressant dans ce projet de disposer d'une base de données afin de pouvoir sauvegarder le tout plus facilement et surtout de pouvoir l'exporter sur d'autre supports.

J'ai donc mis en place une BDD derby que j'ai pris en main. Mais je me colle a un problème…

Devrais-je utiliser seulement des identifiants et faire des requètes a tout va comme pour un site web, ou devrais je créer des classes comme nous le ferions sans BDD que j'initialiserai au besoin via la BDD.

J'ai du mal a y mettre en place et a voir quel marche suivre… Si quelqu'un peut me guider un peu.

L'approche classique, c'est d'utiliser un ORM, Object relational mapping. C'est-à-dire qu'on utilise la base pratiquement que comme médium de stockage et on fait sans cesse la conversion des données extraites de la base vers des objets plus faciles à utiliser dans l'application et vice-versa.

Tu peux te construire un système de conversion très simple qui suffit à tes propres besoins, ou utiliser un framework complet qui s'occupe de tout, hibernate par exemple.

Je pense qu'il est préférable que je fasse mon système de conversion moi même vu sa simplicité, mais je viens de regarder un peu cette technologie dont je ne connaissais que le nom jusque la et ma foi… je n'en comprend pas plus.

Pourrait tu m'expliquer rapidement le principe de base?

Jusque la j'avais penser a faire des itérateurs, qui ce serait occuper de faire des parcours de ma BDD afin de m'en ressortir les différentes lignes. J'aurai ensuite utiliser les valeurs directement ou modéliser certains objet plus complexe si nécessaire avec une méthode save() pour les enregistrer en BDD. Sinon le reste du temps je me serrait contenter de sauvegarder l'ID comme si c'était un objet.

Le seul hic, c'est que j'ai tendance a penser que c'est très sale.

Je ne peux malheureusement pas t'aider beaucoup plus parce que je n'ai jamais utilisé concrètement au-delà d'une petite introduction scolaire. Pour le moment dans tous mes projets perso, je m'en suis toujours sorti avec JDBC seulement, et du MySQL derrière.

Je suis plutôt partisan du coder simple et pratique juste pour ce qu'il faut selon ses besoins, plutôt que de s'attaquer à une usine à gaz dont on ne comprend pas les trois quarts. Je viens de terminer mes études donc je serai sûrement corrompu à mon entrée dans le monde du travail, mais pour le moment c'est mon point de vue.

Je comprend ton point de vue pour les projet personnel. Mais la c'est pour un projet a présenter devant un jury d'admission et j'ai un peu peur de tomber a justifier des attributs ou carrément des classe devant un jury a qui j'essaye de faire croire que je suis compétent xD

Mais merci de ton aide, j'ai même remarquer que le tutoriel Java sur le ZdS comporter une partie entière sur JDBC.

Dans le tuto Java EE, tu as également une grosse partie sur la gestion des BDD, JDBC, DAO et enfin JPA (ORM). J'ai présenté ces concepts dans le contexte d'une appli web, mais le principe est à peu de choses près identique pour une appli desktop.

Mon conseil, c'est que si ton appli n'est pas spécialement massive et n'a pas pour objectif de le devenir, alors tu auras plus vite fait de bricoler un DAO à la main et de faire tes requêtes toi-même (voir cette partie du tuto Java EE pour un exemple d'implémentation).

Je suis assez d'accord avec Coyote. D'autant plus dans une approche pédagogique.

Créer un DAO à la main qui manipule JDBC (avec des itérateurs comme tu le disais, des ResultSet etc.) et te renvoie ce dont les autres couches de l'application ont besoin (des listes d'objets triés etc.) te permettra de mieux comprendre le fonctionnement d'un DAO plus tard.

Pour moi, un ORM prend vraiment du sens quand tu as un modèle avec énormément de relations. Des chiens qui ont chacun un maître qui ont chacun une adresse, qui figure dans le carnet de vaccination, qui est accessible chez chaque vétérinaire, … Bref, du 1..N, N..N, …

Dans ces cas là :

1. les requêtes vont vite devenir complexes, avec des jointures, etc. Tu as toutes les chances de te planter en les écrivant, ou tout au moins d'écrire des requêtes très peu performantes qui vont faire d'énormes produits cartésiens. Avec beaucoup d'expérience et une excellente connaissance de ton modèle tu pourras éventuellement faire mieux que l'ORM, mais c'est très rare, et les ORM généralement le permettent (définir des requêtes "à la main").

2. Le chargement "lazy" des ressources par JPA/Hibernate est également un excellent allier. Si tu ne t'intéresses qu'aux noms des chiens d'un maître donné, il ne va pas aller récupérer la liste des vétérinaires qui ont une copie du carnet de vaccination du chien (jusqu'à ce que tu en fasses la demande dans ton code).

3. Le cache que propose Hibernate (au moins de premier niveau) est également intéressant. En tirer partie t'évite souvent de faire des requêtes inutiles.

Mais pour bien comprendre cela, je pense qu'écrire un DAO simple au moins une fois te permettra de te rendre compte de l'intérêt (ou non, suivant le projet) d'utiliser un ORM.

Bon courage.

Merci a vous deux, je suis bien conscient de l’intérêt de le faire moi même et c'est ce que je vais essayer de faire. De plus ça n'en sera que plus intéressant pour ma soutenance.

Merci a tous.