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, Expert éminent
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?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de souviron34 souviron34 - Expert éminent sénior http://www.developpez.com
le 05/08/2009 à 12:19
Citation Envoyé par davcha  Voir le message
Quel est le meilleur paradigme selon toi ? objet, impératif, fonctionnel, prog par contraintes... ?

Citation Envoyé par GrandFather  Voir le message
Depuis trente ans environ que le concept existe et a été éprouvé dans des projets logiciels de toutes tailles, qu'il a fait l'objet d'innombrables études académiques et de milliers d'ouvrages, on commence à avoir une « petite » idée des forces et des faiblesses du paradigme. .... mais qu'hormis ces cas assez particuliers il y avait tout intérêt à l'adopter. Remettre en cause cette conclusion pourtant pas toute neuve, c'est se complaire dans le combat d'arrière-garde.

Citation Envoyé par GrandFather  Voir le message
mais quid pour modéliser le système informatique qui va l'implémenter ?

Comme dans tous les aspects de la vie courante, en informatique je suis pareil : contre la bien-pensance et le politiquement correct...

Or je ne vois pas de cas de "hormis ces cas assez particuliers il y avait tout intérêt", mais plutôt des esprits formés et formattés par des formations...

Et ce n'est pas de l'arrière-garde, c'est de l'ouverture d'esprit et de la liberté...

Si vous vous sentez bien dans un modèle, tant mieux pour vous..

Mais la Pensée Unique me débecte...

Et ce n'est pas la "réussite" (voir les échecs cuisants, et ne serait-ce que le thread sur "les raisons des échecs") de certains projets qui me feront changer d'avis : je ne crois pas qu'il y ait plus intérêt à adopter une approche plutôt qu'une autre, et je m'insurge contre cela..

Que vous y soyez plus à l'aise car on vous l'a enseigné, et vous avez l'esprit plutôt orienté comme ça, soit..

Mais je ne crois pas que cela amène une meilleure représentation ou réalisation dans l'absolu....

Le fait de dire "Remettre en cause cette conclusion pourtant pas toute neuve, c'est se complaire dans le combat d'arrière-garde" me semble du même acabit que de dire que "le réchauffement climatique est d'origine humaine, c'est prouvé, et tous ceux qui disent le contraire sont des suppôts du Grand Capital"...

PS : d'ailleurs, pourquoi vouloir modéliser un système informatique ???? modéliser des structures de données, soit... Architecturer un système, soit.. Modéliser un système ??

Citation Envoyé par mon_nom_est_personne  Voir le message
Je trouve que le cote objectivement "meilleur" de la question est un peu reducteur.
... Encore une fois, la grosse erreur c'est de faire rentrer un projet dans une techno ou un paradigme au lieu de l'inverse.

+10000


Citation Envoyé par pseudocode  Voir le message
Bah, des modèles y en a plein : depuis la discussion sur dictaphone avec les experts jusqu'aux modélisations formelles. Ce que je rencontre le plus fréquemment c'est la représentation "patatoide" avec flèches et annotations.




Citation Envoyé par pseudocode  Voir le message
heu... utiliser le cerveau de l'architecte ! Désolé mais je ne connais pas de méthode formelle pour faire ce genre de chose.
....
Ce sont les contraintes de cette zone grise qui m'orientent dans des choix techniques (vue dynamique ou pré-calculée, sérialisation binaire ou représentation DDL, stockage "raw" en base ou indexation de fichier, ...).

Bref, pas de solution miracle. Juste essayer de quantifier un minimum les objectifs/risques fonctionnels et de s'occuper du plus important/risqué d'abord.

+10000



Citation Envoyé par GrandFather  Voir le message
Cela dit, je le répète, on parle ici d'un choix méthodologique à opérer dans un contexte objet. Donc la réponse du style « ben t'as qu'à pas utiliser d'objet et le problème est réglé » relève au mieux de la boutade, au pire du troll. J'ose espèrer que la première hypothèse est la bonne ?


Non, voir ci-dessus..

Mais j'arrête là ma participation... Ne pouvant donner qu'un point de vue de logique et non d'argumentaire technique...
Avatar de GrandFather GrandFather - Expert éminent http://www.developpez.com
le 05/08/2009 à 12:56
@souviron: Je ne commenterai même pas ce délire sur la « pensée unique » et me contenterai de répondre à ce qui n'a qu'un rapport, même lointain, avec la discussion :
Citation Envoyé par souviron34  Voir le message
PS : d'ailleurs, pourquoi vouloir modéliser un système informatique ???? modéliser des structures de données, soit... Architecturer un système, soit.. Modéliser un système ??

Je travaille dans une entreprise comportant une dizaine de centres informatiques régionaux, une centaine de centres départementaux, des centaines d'applications métiers front-end, des process de production complètement automatisés, et des interactions complexes avec des entreprises tierces. Comment fait-on pour comprendre et appréhender sous une forme synthétique ne serait-ce qu'une fraction d'un tel ensemble sans employer une quelconque forme de modélisation ? En relisant toutes les lignes de code et en épluchant les bons de livraison fournisseur ?

P.S. (tout de même) : puisque le « vous » de « Que vous y soyez plus à l'aise car on vous l'a enseigné, et vous avez l'esprit plutôt orienté comme ça, soit.. » m'inclut vraisemblablement, je peux au moins répondre en mon nom propre. Etant totalement autodidacte, je ne peux même pas incriminer l'enseignement pour expliquer mon « formatage » et ma soumission à la « pensée unique ». C'est de la pure auto-suggestion.
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 05/08/2009 à 23:02
Je crois surtout que ce qui est important, c'est que la théorie de façon excessive est nuisible car elle écarte de la réalité.
C'est un peu là qu'est l'ambiguité de la bonne approche : elle peut être bonne dans son contexte, et très mauvaise d'un point de vue académique.

La trop grosse croyance dans la théorie peut amener à des catastrophes sans nom, de même que l'ignorance des fondamentaux.

Comme dirait l'autre il y a 3 méthodes : la bonne, la mauvaise, et la mienne.

Pour réussir un projet que qu'il soit, il faut
1 dose d'organisation
1 dose de technicité
1 dose d'implication
1 dose de sens client
1 trait de génie
1 équipe homogéne
1 techno saine et connue de l'équipe

Ben mine de rien, cette recette à l'air si anodin, c'est le souflé au fromage : tout le monde en parle, tout le monde connait la recette, pourtant, tous les jours, tout le monde le rate.
Avatar de nico1407 nico1407 - Nouveau membre du Club http://www.developpez.com
le 06/08/2009 à 10:07
La création de la base de données par des annotations dans le code n'est pas une solution idéale.

La conception de la base ne passe même plus par un DBA pour optimisation et on assiste à du n'importe quoi de la part des developpeurs qui n'ont pas le niveau en SGBD.

J'ai vu un projet qui a commencé avec la création de la base par annotation, à la 2e version de l'application l'équipe est revenu à faire ses scripts SQL à la main, manque d'index, contrainte unicité...

Il est dangereux de faire évoluer sa base par "magie" avec les framework, on arrive à un point où les équipes de développement ne savent même plus ou ne veulent plus chercher à comprendre la gestion d'une BDD.
Avatar de _skip _skip - Expert éminent http://www.developpez.com
le 06/08/2009 à 10:27
C'est ce que je soupçonnais en fait, trop d'abstraction risquerait de couper court aux optimisations que l'on peut réaliser par modélisation (éviter les jointures qui servent à rien, préférer rassembler les entités héritées dans une même table plutôt que d'éclater sur plusieurs tables suivant la situations etc..)

Pour la défense de Souviron, je dirai que ça m'arrive souvent d'utiliser des objets comme de vulgaires structures, des POJO IBatis notamment lorsqu'il s'agit de devoir lire et présenter / utiliser rapidement des données provenant de BDD.
C'est pas compatible avec la théorie du bô domaine full OO, c'est quasiment pas de l'objet, mais ça fait exactement ce que je demande et c'est performant.

Citation Envoyé par B.AF

Je crois surtout que ce qui est important, c'est que la théorie de façon excessive est nuisible car elle écarte de la réalité.
C'est un peu là qu'est l'ambiguité de la bonne approche : elle peut être bonne dans son contexte, et très mauvaise d'un point de vue académique.

+250000, J'ai vécu l'expérience de faire des choses contre mon intuition pour obéir aux bonnes pratiques (notamment en matière de d'abstraction et de couplage). Ben je dois dire que c'est arrivé que la complexité inutile ajoutée me retombe dessus...
Comme on a déjà dit, si le résultat est maintenable et satisfait le client dans les délais, le reste n'est que littérature.
Avatar de GrandFather GrandFather - Expert éminent http://www.developpez.com
le 06/08/2009 à 10:55
Citation Envoyé par _skip  Voir le message
Pour la défense de Souviron, je dirai que ça m'arrive souvent d'utiliser des objets comme de vulgaires structures, des POJO IBatis notamment lorsqu'il s'agit de devoir lire et présenter / utiliser rapidement des données provenant de BDD. C'est pas compatible avec la théorie du bô domaine full OO, c'est quasiment pas de l'objet, mais ça fait exactement ce que je demande et c'est performant.

Je le fais aussi, et quand j'utilise l'ORM de manière plus poussée c'est en en faisant le « client » de la BDD et pas l'inverse. La position de souviron est à un tout autre niveau : il ne voit même pas l'intérêt de l'objet en général, alors nos nuances « conception full OO » ou « conception mixte OO/SGBDR » lui passent un peu au dessus de la tête...
Citation Envoyé par _skip  Voir le message
Comme on a déjà dit, si le résultat est maintenable et satisfait le client dans les délais, le reste n'est que littérature.

Si tu as réussi à remplir ces 2 objectifs, hélas souvent difficile à concilier dans un contexte professionnel tendu, c'est que, pour reprendre la métaphore pertinente de B.AF, tu as réussi ton soufflé.
Avatar de el_slapper el_slapper - Expert éminent sénior http://www.developpez.com
le 06/08/2009 à 11:22
Citation Envoyé par GrandFather  Voir le message
(.../...)

Je travaille dans une entreprise comportant une dizaine de centres informatiques régionaux, une centaine de centres départementaux, des centaines d'applications métiers front-end, des process de production complètement automatisés, et des interactions complexes avec des entreprises tierces. Comment fait-on pour comprendre et appréhender sous une forme synthétique ne serait-ce qu'une fraction d'un tel ensemble sans employer une quelconque forme de modélisation ? En relisant toutes les lignes de code et en épluchant les bons de livraison fournisseur ?
(.../...)

Je suis globalement d'accord avec souviron, sauf sur ce point là. Quand le système d'information devient massif(plusieurs milliers de personnes à l'informatique dans une grande banque française), une nouvelle couche d'industrialisation est obligatoire pour retrouver ses petits. Le programme est une industrialisation d'un processus métier, mais l'informatique elle-même est à industrialiser. Pas pour qu'elle soit meilleure(au contraire, ça pousse à des standards pas toujours adaptés), mais pour qu'elle soit gérable. Mieux vaut 2 mauvais projets compatibles que deux bons incompatibles..... Évidement, dans la PME du coin, le raisonnement ci-dessus n'a aucun sens.
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 06/08/2009 à 17:33
Citation Envoyé par el_slapper  Voir le message
Je suis globalement d'accord avec souviron, sauf sur ce point là. Quand le système d'information devient massif(plusieurs milliers de personnes à l'informatique dans une grande banque française), une nouvelle couche d'industrialisation est obligatoire pour retrouver ses petits. Le programme est une industrialisation d'un processus métier, mais l'informatique elle-même est à industrialiser. Pas pour qu'elle soit meilleure(au contraire, ça pousse à des standards pas toujours adaptés), mais pour qu'elle soit gérable. Mieux vaut 2 mauvais projets compatibles que deux bons incompatibles..... Évidement, dans la PME du coin, le raisonnement ci-dessus n'a aucun sens.

Si je prend une de ces boites justement il y a peu, un des "grands architectes" m'a expliqué que finalement ils avaient abandonnés hibernate au profit d'outils "plus simples" (dixit). Ils ont recentrée leur activité sur un SGBD, et monté un pôle de compêtence "accès aux données", avec des formations business intensives aux développeur qui donnent d'excellent résultat. Je ne dis pas que c'est mon approche favorité, mais c'est un bon exemple de la vie de tous les jours qui prouve que la solution n'est pas technique, mais décisonnelle. La décision étant ici :
- De réduire les risques de modélisation (connaissances métiers)
- De réduire les redondances (dépôt de domaine)
- De réduire les risques technolgiques

Après il y a la réalité aussi
Avatar de SQLpro SQLpro - Rédacteur http://www.developpez.com
le 04/01/2010 à 10:58
Posez-vous les bonnes question...
Posez vous la question de savoir qu'est ce qui est bon pour la qualité des développements ?
Posez vous la question de la pérénité des outils ?

Que voyez vous ?

Moi je voit des sytèmes stables, parce que matures et rarement remis en question même si on tente de le faire croire. Je voit dans ce lot les SGBD en particulier (30 ans aujourd'hui...). Les épyphénomène tel que le cloud computing avec Azure ou BigTable, n'étant que des bluff marketing et ne remettent pas du tout les fondements des bases de données relationnelles...
A côté de cela je voit tout un tas de systèmes instables basé sur des frameworks... Renouvellement technologique tous les 6 mois ! Vous avez dit stabilité ???

Si vous voulez édifier un bâtiment, préférez vous le faire sur du sable mouvant, ou bien sur une dalle en béton armé ?

Quand aux centaines de tables qu'il faut traverser pour accéder à une donnée dans un modèle relationnel, moi je me pose la question suivante : si tel est le cas, alors c'est qu'il y a besoin d'un modèle relationnel. Donc autant le faire le mieux possible. Parce qu'il n'existe qu'une seule alternative : soit tout mettre à plat, soit réaliser un vrai modèle relationnel. Les gens qui tentent une approche hybride ou bien n'accordent aucune importance à la qualité du modèle (par exemple lorsqu'il oublient de le concevoir et laisse faire un ORM), se retrouvent tôt ou tard piègés et s'avère benoitementg insatisfait des possibilité du SGBDR alors qu'ils l'ont sciemment ignoré !

A +
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 05/01/2010 à 10:39
Citation Envoyé par SQLpro  Voir le message
Posez-vous les bonnes question...
Posez vous la question de savoir qu'est ce qui est bon pour la qualité des développements ?
Posez vous la question de la pérénité des outils ?

Que voyez vous ?

Moi je voit des sytèmes stables, parce que matures et rarement remis en question même si on tente de le faire croire. Je voit dans ce lot les SGBD en particulier (30 ans aujourd'hui...). Les épyphénomène tel que le cloud computing avec Azure ou BigTable, n'étant que des bluff marketing et ne remettent pas du tout les fondements des bases de données relationnelles...
A côté de cela je voit tout un tas de systèmes instables basé sur des frameworks... Renouvellement technologique tous les 6 mois ! Vous avez dit stabilité ???

Si vous voulez édifier un bâtiment, préférez vous le faire sur du sable mouvant, ou bien sur une dalle en béton armé ?

Quand aux centaines de tables qu'il faut traverser pour accéder à une donnée dans un modèle relationnel, moi je me pose la question suivante : si tel est le cas, alors c'est qu'il y a besoin d'un modèle relationnel. Donc autant le faire le mieux possible. Parce qu'il n'existe qu'une seule alternative : soit tout mettre à plat, soit réaliser un vrai modèle relationnel. Les gens qui tentent une approche hybride ou bien n'accordent aucune importance à la qualité du modèle (par exemple lorsqu'il oublient de le concevoir et laisse faire un ORM), se retrouvent tôt ou tard piègés et s'avère benoitementg insatisfait des possibilité du SGBDR alors qu'ils l'ont sciemment ignoré !

A +

Super comme approche....Et dans ce cas, on reste en cobol aussi.
Le tas de système instable basé sur des Frameworks, c'est vraiment fait exprès ?
Hibernate a plus de 9 ans, topplink depuis 9 ans,ADO.Net 8 ans...

L'image avec le bâtiment est benoite : le matériaux est à déterminer à priori. C'est le travail de l'architecte.

Pour faire mieux, on peut avoir une base dont le modéle est parfait, mais dont l'exploitation est mauvaise, et réciproquement.

Le tout SQL n'est pas une solution viable dans tous les cas, et si ce n'est pas le cas, il faut aussi reconnaitre l'existance d'autres solutions et savoir s'en servir avant de les jetter avec l'eau du bain.

C'est le cas des caches distribués (memcache, probablement un truc encore instable qui tient wikipédia), des systèmes sur gros volumes (genre ebay qui découvre que les transactions sont un goulet d'étranglement).

C'est aussi la question du commit et du rollback et d'une façon générale de l'utilité de la transaction :
Si j'ai analysé correctement tous les workflows métiers et si j'ai pris en compte tous les risques de locks, pourquoi devrais-je prendre la sécurité de pouvoir annuler une transaction ? C'est intellectuellement superflu ?

Dans SQL 2005 et 2008 avec des sp en .Net, on peut faire des horreurs. La distribution de services depuis la base peut être une cata!

L'essentiel d'un code base c'est de contrôler l'intégralité des éléments et que l'ingénierie soit cohérente.
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 05/01/2010 à 11:36
Citation Envoyé par SQLpro  Voir le message
Moi je voit des sytèmes stables, parce que matures et rarement remis en question même si on tente de le faire croire. Je voit dans ce lot les SGBD en particulier (30 ans aujourd'hui...). Les épyphénomène tel que le cloud computing avec Azure ou BigTable, n'étant que des bluff marketing et ne remettent pas du tout les fondements des bases de données relationnelles...
A côté de cela je voit tout un tas de systèmes instables basé sur des frameworks... Renouvellement technologique tous les 6 mois ! Vous avez dit stabilité ???

C'est plutot une réflexion pour la discussion sur le débat "No-SQL".

Qu'on utilise une BDDR connue, un simple btree, ou la toute dernière techno de persistance en ligne, le problème de la modélisation reste entier.

Je ne vois pas en quoi utiliser une modélisation SQL rend les choses plus simple quand il s'agit de modéliser des relations ternaires.
Offres d'emploi IT
Creative front-end dev #angular #ux
Adequat Tertiaire - Rhône Alpes - Lyon (69000)
Développeur web laravel h/f
Canaljob.fr - Ile de France - Paris (75000)
Architecte / expert microsoft h/f
Sogeti France - Rhône Alpes - Lyon (69000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil