Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Conception : L'approche "Model First" n'est-elle pas plus saine que l'ancestrale approche "Schema First"
S'appuyant sur le SGBDR ?

Le , par _skip

0PARTAGES

0  0 
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?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Emmanuel Lecoester
Membre expert https://www.developpez.com
Le 27/06/2009 à 14:37
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 .
0  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 27/06/2009 à 15:22
Citation Envoyé par Emmanuel Lecoester Voir le message
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..
0  0 
Avatar de Tommy31
Membre chevronné https://www.developpez.com
Le 28/06/2009 à 15:24
Citation Envoyé par souviron34 Voir le message
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 !

Citation Envoyé par souviron34 Voir le message

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.

Citation Envoyé par souviron34 Voir le message

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é).
0  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 28/06/2009 à 18:59
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.
0  0 
Avatar de Plageman
Membre régulier https://www.developpez.com
Le 28/06/2009 à 22:27
Citation Envoyé par _skip Voir le message
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é...
0  0 
Avatar de Emmanuel Lecoester
Membre expert https://www.developpez.com
Le 29/06/2009 à 9:26
Citation Envoyé par _skip Voir le message
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) ?
0  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 29/06/2009 à 10:31
Citation Envoyé par Tommy31 Voir le message
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...
0  0 
Avatar de TheLeadingEdge
Membre expert https://www.developpez.com
Le 29/06/2009 à 13:46
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.
0  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 29/06/2009 à 13:59
Citation Envoyé par TheLeadingEdge Voir le message
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)
Mais elle n'a même pas à savoir ce que c'est que la persistence !!!!

Par contre, la BD n'a rien à savoir de ce qu'on fait avec les données. Elles est purement fournisseuse...

Or je vois (et je suis désolé, cela figure beaucoup dans ce que je vois dans le forum Conception) des modèles où on applique des "join", des "where", etc etc..

Et, qui plus est, où on introduit (dans du code Java, Php, C++, ou n'importe quoi) des requêtes SQL (ou mysql, mais c'est strictement pareil), dans du code d'IHM, dans du code métier, etc etc...

La combinaison des 2 effets me paraît catastrophique...

C'est tout.
0  0 
Avatar de TheLeadingEdge
Membre expert https://www.developpez.com
Le 29/06/2009 à 14:16
Mais elle n'a même pas à savoir ce que c'est que la persistence !!!!
Oui mais on serait dans un mode parfait. Pour l'instant ce qui s'en rapproche le plus c'est d'utiliser un fwk qui mappe automatiquement les 2.

Par contre, la BD n'a rien à savoir de ce qu'on fait avec les données. Elles est purement fournisseuse...
Encore ''oui mais'' (désolé ). La bdd est la mémoire, le métier est l'intelligence. Mais les 2 couches doivent être cohérentes entre elles. Il existe tout de même un lien entre les données qui sont travaillées ds la couche métier et l'organisation des données stockées ds la base (ou vice-versa)

des modèles où on applique des "join", des "where", etc etc..
Il faut bien entrer et sortir les données. Dans la couche de persistance, le SQL ''c'est pas sale'' ?

Et, qui plus est, où on introduit (dans du code Java, Php, C++, ou n'importe quoi) des requêtes SQL (ou mysql, mais c'est strictement pareil), dans du code d'IHM, dans du code métier, etc etc...La combinaison des 2 effets me paraît catastrophique...
Là je ne peux qu'être totalement d'accord. C'est une horreur.
0  0