Discussion :

[_skip]

Bonjour,

Ce sujet fait suite aux récentes discussions sur ce forum concernant les ORM, les problèmes rencontrés au niveau de la qualité du design des bases de données et la capacité d'indépendance offerte par ce type d'outil par rapport aux différentes bases de données du marché.

Dans mon expérience, une application orientée base de données a toujours démarré (sans compter les phases plus orientées analyse, organisation, faisabilité) par la création du schéma de base de données. Ensuite seulement venait la partie ORM / mapping par rétro ingénieurie pour la création du *client* de cette BDD. (approche schema-first)

Maintenant qu'un certains nombres d'outil et de frameworks d'OR/mapping vous propose l'inverse, c'est à dire vous écrivez vos classes en c# ou en java vous ajoutez quelques annotations au tout et vous générez la base de donnée qui va avec par forward-engineering. (Model first).

Dans leurs discours commerciaux, ces outils vous promettent :

-Une productivité sans égale.
-Du code indépendant de la base de donnée finale parmi celles supportées.
-La persistence transparente.
-La prise en charge de la migration en cas d'évolution du schéma BDD.

Les outils stables proposant cette approche dont j'ai entendu parler jusqu'ici sont :

-XPO
-OpenAccess

Alors les vraies questions sont :

-Avez-vous des retours d'expérience d'utilisation d'approches model first?
-Croyez-vous en ce genre de pratique et si oui jusqu'à quel point?

[Emmanuel Lecoester]

Le mariage OO - relationnel n'est qu'un middleware. Maintenant qu'on fasse :

• modèle OO -> génération relationnel
• modèle relationnel-> génération OO
• modèle relationnel, modèle OO, ORM

Au final on perdra d'un coté ou de l'autre...

Un de ces jours on remettra tout dans des fichiers texte vu que le développeur dotnet nous annoncent "la base de données on s'en fout c'est la DAL qui le gère".

J'ai vu une approche "model first" en 1999 où c'était l'IHM qui pilotait le modèle de base de données, sur les 8 lots du projet seuls les deux premiers ont vu le jour vu qu'à chaque lot on revoyait le modèle .

[souviron34]

Le mariage OO - relationnel n'est qu'un middleware. Maintenant qu'on fasse :

• modèle OO -> génération relationnel
• modèle relationnel-> génération OO
• modèle relationnel, modèle OO, ORM

Au final on perdra d'un coté ou de l'autre...

Un de ces jours on remettra tout dans des fichiers texte vu que le développeur dotnet nous annoncent "la base de données on s'en fout c'est la DAL qui le gère".

J'ai vu une approche "model first" en 1999 où c'était l'IHM qui pilotait le modèle de base de données, sur les 8 lots du projet seuls les deux premiers ont vu le jour vu qu'à chaque lot on revoyait le modèle .

Pour moi, cela fait longtemps que c'est la base de ma pensée...

Dans 99.999999% des cas que j'ai vu, utiliser une SGBD était tout simplement un "trip" ou un à-priori d'informaticiens ou de boîtes...

Dans la pratique, à quelques (très rares) exceptions près, cela complique très nettement le choses, sans parler des coûts qui explosent...

Je ne suis pas contre à priori, je suis contre l'utilisation d'un bulldozer pour écraser une mouche...

Et en effet, de ce que je vois depuis une 15 aine d'années avec l'OO, sa modélisation, et les possibilités offertes par des outils/langages.. comme SQL, je pense fondamentalement que dans le principe il y a un bug....

Quand on demande à faire une opération complexe, c'est une opération métier. Cela devrait donc être à la couche métier de la faire. Et de plus, comme c'est métier, cela devrait être indépendant de la manière dont les données sont stockées/gérées, et donc indépendant de la BD..

Or je ne vois apparaître que de plus en plus de liens, et de plus en plus d'imbrication de la BD avec les données et le métier...

Pour moi, une bonne application portable et indépendante devrait considérer à la base être répartie et multi-BD, et donc indépendante de SQL etc (avec par exemple certaines données sous Oracle, d'autres sous Access, d'autres dans des fichiers textes etc etc..).

UNIQUEMENT à cette condition on aurait alors une vraie analyse, et une vraie séparation et indépendance...

Mais visiblement les forces du marketing et des modes sont plus fortes que le bon sens

Sans parler des problèmes de perfomances, où pour accéder à une donnée il faut passer à travers 250 tables différentes..

[Tommy31]

Quand on demande à faire une opération complexe, c'est une opération métier. Cela devrait donc être à la couche métier de la faire. Et de plus, comme c'est métier, cela devrait être indépendant de la manière dont les données sont stockées/gérées, et donc indépendant de la BD..

Ca, ca fait plaisir à lire !

Pour moi, une bonne application portable et indépendante devrait considérer à la base être répartie et multi-BD, et donc indépendante de SQL etc (avec par exemple certaines données sous Oracle, d'autres sous Access, d'autres dans des fichiers textes etc etc..).

Bien qu'idéaliste, je partage cette conviction. Cependant dans les cas concrets et sous le joug de fortes contraintes de temps, on s'assoit vite sur ces bons principes.

Mais visiblement les forces du marketing et des modes sont plus fortes que le bon sens

De quelle mode parles-tu ? Il me semble que la mode justement est aux architectures en couche avec une segmentation claire des responsabilités, et une indépendance marquée entre elle (couplage relaché).

[_skip]

C'est intéressant, car ce que toi et Souviron soutenez est exactement l'approche fustigée par SQLPro dans son article et sur ce même forum.

[Plageman]

C'est intéressant, car ce que toi et Souviron soutenez est exactement l'approche fustigée par SQLPro dans son article et sur ce même forum.

A nous autres non expert de trouver notre vérité...

[Emmanuel Lecoester]

C'est intéressant, car ce que toi et Souviron soutenez est exactement l'approche fustigée par SQLPro dans son article et sur ce même forum.

C'est exactement ce que je me disais aussi.

Les bases de ces deux approches sont parfaitement recevables.

Dans le cas du modèle OO drivant le modèle relationnel, quel interet à passer sur un SGBDR ? pourquoi n'utilisez vous pas un SGBDOO cela éviterai les couches ORM et vous auriez une vraie gestion OO .

Pour la partie bases de données épaisses j'accroche un peu plus car combien d'applications sont développées avec les dernières technologies (dot, java,...) tout en gardant le modèle d'origine d'il y a quelques années (qu'il soit bon ou mauvais) ?

[souviron34]

De quelle mode parles-tu ? Il me semble que la mode justement est aux architectures en couche avec une segmentation claire des responsabilités, et une indépendance marquée entre elle (couplage relaché).

Je ne sais pas, de ce que je vois sur les forums ici et là...

Que ce soit en développements Web, sur le forum Conception, ou sur le forum BD...


Je trouve les schémas, modélisations, etc etc, et BDs très très très fortement liées (via la BD, via un outil)..

Et l'utilisation d'UML ou de MCD comme des Dieux en fait partie...

[TheLeadingEdge]

Je trouve les schémas, modélisations, etc etc, et BDs très très très fortement liées (via la BD, via un outil)..

Et l'utilisation d'UML ou de MCD comme des Dieux en fait partie...

Ce n'est pas du tout ce que l'on essaie de faire passer comme message dans Conception!! Au contraire!
On y parle d'orthogonalité, de forte cohésion, faible couplage, séparation des responsabilités...
La persistance (mémoire) de l'appli est gérée par un SGDBr. On fait un modèle ad hoc. Pour moi c'est encore 1 MLD.
Et si la cible est 1 SGBD00 c'est un DC UML spécialisé.
Le métier (l'intelligence) c'est un autre modèle (DC UML). La couche métier n'a pas a savoir comment les données sont persistées. Elle délègue de façon transparente à une couche service (DAL/DAO)
La couche service de persistance c'est avec un framework. Hibernate par exemple parce que je pense que c'est le plus évolué (mais d'autres en préfèreront un autre et auront aussi raison).
Plus les 2 modèles à mapper seront propres, plus le mapping auto sera de bonne qualité. Mai pour l'instant le meilleur ''mapper'' reste le dev. Et il ne faut pas s'imaginer que HB8 est une baguette magique qui va corriger les erreurs de conception et faire un bon travail à partir de bases cochonnées.
On peut faire du boulot trés propre et trés fin avec un framework. Mais il ne sufit pas de cliquer sur 2 boutons pour générer un modèle générique et ensuite dire que l'outil fait de la merde. Ou à l'inverse bidouiller dans le mapping sans se poser de question sur l'intelligence de ce qu'on fait pour corriger des erreurs ou des manques dans les modèles données ou métier. Ca nécessite un minimum de compétences.

Dans 99.999999% des cas que j'ai vu, utiliser une SGBD était tout simplement un "trip" ou un à-priori d'informaticiens ou de boîtes...

Dans ceux ou je travaille, c'est 99,9% obligatoire. Mais c'est du à un domaine différent sans doute (info de gestion)

pourquoi n'utilisez vous pas un SGBDOO cela éviterai les couches ORM et vous auriez une vraie gestion OO .

. Tu t'es déjà battu avec les pointeurs d'une appli en c qui gère les objets dans un base oo ?
XML c'est un caviar à faire.