Discussion :

[Tofalu]

Bonjour,

Je ne connais pas bien la notion de model first, à vrai dire, j'ai toujours pratiqué comme GrandFather le schema first.

Mais je me pose une question : comment est géré la cohérence et l'intégrité des données lorsque la base est attaquée par une autre application conçue par un autre développeur si aucune contrainte n'y sont définie ?

Et comment vous gérez les transactions de données ?

[_skip]

Les fonctionnalités de forward engineering d'un ORM "model first" permettent de génèrer les contraintes de clefs étrangères d'après les propriétés d'une classe d'entité dont le type correspond à une autre classe d'entité, c'est souvent fait à l'aide d'annotations.

Un exemple avec XPO

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class OrderLine : XPObject 
{
  public string Description;
  public double Price;
  public int Quantity;

  [Association("OrderLines")]
  public Order Order;
}

public class Order : XPObject 
{
  public string OrderNo;
  public string Description;

  [Aggregated, Association("OrderLines", typeof(OrderLine))]
  public XPCollection OrderLines 
  {
    get { return GetCollection("OrderLines"); }
  }
}

[Tofalu]

Ok

C'est le post de grandfather qui m'a induit en erreur. En le lisant j'avais compris, à tord, que pour lui seule l'approche Schema first permettait de placer les contraintes dans la base.

[B.AF]

Ok

C'est le post de grandfather qui m'a induit en erreur. En le lisant j'avais compris, à tord, que pour lui seule l'approche Schema first permettait de placer les contraintes dans la base.

Dans les deux cas, le risque d'erreur est fort :

sur le Schema first, tu as un risque de récursivité du à la transposition relationnelle / objet

sur le Model first, tu as un risque d'erreur du à la génération de code.

Personnellement, j'ai tendance à utiliser le Model First, mais à soumettre le schéma à un "gourou" sql, qui le torture et le check.

Mais dans les deux cas, l'erreur peut couter TRES cher.

[GrandFather]

En le lisant j'avais compris, à tord, que pour lui seule l'approche Schema first permettait de placer les contraintes dans la base.

Je n'ai peut-être pas été assez précis. Les contraintes auxquelles je faisais référence sont des règles métiers implémentées sous forme de triggers ou de clauses CHECK, sans effets de bord. A ma connaissance aucun framework de persistance n'est encore apte à les générer.

Les frameworks de persistance gèrent les contraintes d'intégrité référentielle, de manière transparente pour le développeur. Le problème, enfin pour moi, c'est que cette transparence se transforme en opacité lorsqu'il s'agit de faire un tuning de la base pour améliorer les performances, impliquant une dénormalisation par exemple. Or, dans mon domaine (les applications Web), les principaux goulets d'étranglement sont généralement au niveau de la base.

J'utilise toutefois des ORM, mais j'en fais la même utilisation que _skip : un mapping simple qui me facilite les opérations CRUD et minimise la présence de code SQL dans mon application. Pour des requêtes du style Maître/Détails j'utilise des vues créées dans le SGBDR, qui sont mappées côté application comme de simples tables.

[souviron34]

juste pour .. rigoler ?? pleurer ??

et appuyer ce que je disais plus haut , voici une (petite, toute seule, il y en avait plus de 800 comme ça) page de description de BD ...

Alors Model First ou Schema First...

[Tommy31]

C'est un fake !

[souviron34]

C'est un fake !

si seulement !!!

Mais non...

Comme je le disais, non seulement un mur entier, mais qui plus est chaque nouvelle fonctionalité avait droit à ce genre de petit schéma...

[davcha]

Tu devrais penser à renouveler tes anecdotes, souvirounet.

[souviron34]

Tu devrais penser à renouveler tes anecdotes, souvirounet.

ayant deleté l'attachement de là où je l'avais posté il y a sans doute plus d'un an 1/2, ça vaut le coup de le remettre..

Je m'excuse mais je trouve que c'est cependant un (bon) exemple de ce que peuvent amener des "modèles" en oubliant une pensée logique...




Et au vu de ce qu'on voit sur MCD, modèles, conceptions, méthodes, modélisations, nouveaux "all-in-one solutions", "never any problem anymore" etc etc, ce n'est pas fini...


Je ne demande pas mieux que d'avoir d'autres exemples de votre part

[GrandFather]

Je ne demande pas mieux que d'avoir d'autres exemples de votre part

Etant donné que tu ne vois déjà pas l'intérêt de la POO (tu t'es suffisamment exprimé sur le sujet pour qu'il n'y ait pas d'ambiguïté), je pense assez vain d'essayer de te démontrer la pertinence d'une modélisation objet/relationnel (et il me semble aussi avoir compris que tu étais un peu faché avec le relationnel)...

[davcha]

De mon côté, ça sera difficile pour le moment, comme je suis encore indépendant jusqu'en septembre au moins.

Mais vu ce que certaines personnes racontent ici et là, j'ai bien envie de dire qu'il doit y avoir pas mal d'exemples de conceptions foireuses....

C'est à se demander comment ils en sont arrivés à ces horreurs, d'ailleurs.

[GrandFather]

Mais vu ce que certaines personnes racontent ici et là, j'ai bien envie de dire qu'il doit y avoir pas mal d'exemples de conceptions foireuses....

Bien évidemment. Si le fait d'utiliser une méthode de conception quelle qu'elle soit garantissait le succès, on pourrait diviser l'effectif de notre profession par 2. C'est comme utiliser un revolver : bien maîtrisé c'est mortel à plusieurs dizaines de mètres, maintenant il est toujours possible de se tirer dans le pied.

[davcha]

Je me demande si ces conceptions foireuses sont pas dues à la façon dont sont enseignées des méthodes comme Merise, etc...

[B.AF]

Je me demande si ces conceptions foireuses sont pas dues à la façon dont sont enseignées des méthodes comme Merise, etc...

Ah non, elles sont la triste conséquence de comportements bien humains.

[TheLeadingEdge]

[...] voici une (petite, toute seule, il y en avait plus de 800 comme ça) page de description de BD ...

Alors Model First ou Schema First...

Ca ressemble à rien cet exemple. Au mieux c'est de la boxologie.
Ca confirme juste qu'un truc mauvais eh bien ... il est mauvais.
C'est clair que partir de ça pour developper ça n'a pas du être simple. Mais se baser là dessus pour généraliser et déduire que la modélisation est inutile c'est du jésuitisme.

Dans la même veine je peux faire pire.
100% des bugs sont dans le code. Si on supprime le code on supprime les bugs.
Donc les developpeurs (et peuses) vous êtes le maillon faible, au revoir.

[mon_nom_est_personne]

petite question concernant le model first et l'orm:
Imaginons que vous devez partager les donnees entre plusieurs applications distinctes sur different serveur, comment vous faites?

[benwit]

J'ai lu les précédents posts et j'en retiens principalement deux idées :

Celle de maximilian :

Le concepteur/développeur objet va vouloir du top-down avec un ORM qui lui permet de se contrefoutre du SGBD.
Le DBA va préférer du bottom-up voire pas d'ORM voire une thick database contenant le métier.
Chaque monde contemple l'autre en le méprisant sans trop le connaitre...

Tellement vrai.

Celle de _skip / GrandFather

J'utilise toutefois des ORM, mais j'en fais la même utilisation que _skip : un mapping simple qui me facilite les opérations CRUD et minimise la présence de code SQL dans mon application. Pour des requêtes du style Maître/Détails j'utilise des vues créées dans le SGBDR, qui sont mappées côté application comme de simples tables.

+1

Ma position est la suivante :

1. On n'a pas vraiment un choix énorme pour la persistance des données.
   On a principalement les fichiers et les sgbdr ? je ne connais pas d'autres solutions éprouvées/performantes/utilisées (merci de m'éclairer sinon)
   Si j'ai des craintes (irrationnelles ?) de mettre des mp3, des divx ou des images dans des blobs du sgbd (j'ai peur qu'il explose ), je trouve cependant beaucoup davantage au sgbdr. Ceci dit, il me sera dur de me passer du SQL. (Peut être quand GAE/BigTable de Google sera au point mais c'est encore loin d'être le cas)
2. J'aime particulièrement la POO (je dois avoir l'esprit fait pour) ... Si seulement mes objets pouvaient persister tout seuls
   Pour moi, de ce point de vue, l'approche model first est la meilleure car ces objets, ce sont justement ces objets métiers qui colle au domaine, qui sont indépendants du moyen de persistence ...
   Si j'ai bien compris, il me semble que ce sont justement ces objets métiers que souhaite souviron mais il rejette également cette notion de model ? ...
   Bref, j'ai du mal à le suivre ... Soit on n'entend pas bien la même chose par modèle, soit ? ...
3. Considérant les points 1 et 2, on se retrouve à avoir du code SQL dans notre application (développée en objet). Où mettre ce code SQL ?
   Dans la bdd ? Des traitements applicatifs côté base, cela ne me plaît pas trop. A la rigueur, le réserver pour des vues particulières des données si ça améliore les performances.
   De toute façon, le code SQL nous sert alors à faire les opérations CRUD pour lire/écrire des POJOs et je ne veux pas que ce code SQL vienne "contaminer" mon application si je veux garder l'indépendance.
   En utilisant une interface d'accès aux données, on se rapproche de ce que suggère souviron, j'ai un service qui me fournit les données, point barre.
   J'ai une implémentation avec des Mocked Object pour des tests, une implémentation SGBD avec du code SQL, une implémentation par WebService, ... et si je souhaite autre chose, je ne réécris qu'une autre implémentation.
   Le lien entre le modèle logique (modèle objet) et un modèle physique (schéma de bdd, structure de fichiers, description wsdl du webservice) doit bien être fait quelque part et autant le découpler, on est d'accord.

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

Pour un projet, j'ai voulu dernièrement aller contre la tendance de mon chef qui résonne exclusivement "merise" en adoptant une approche model first.
Je trouve qu'avec les annotations en Java et un ORM, c'est un plaisir dans qu'on reste dans des cas simple. Après, pour des besoins plus complexe, il faut du temps pour comprendre la logique de l'ORM, temps qu'il était censé nous faire gagner ... Pour des questions de planning, j'ai été amené à mettre de côté mon implémentation par ORM pour revenir à une implémentation manuelle (mapping à la main, via IBatis). Heureusement, avec mon découplage par mon service d'accès aux données, cela s'est fait sans douleurs (J'ai même gagné une table que l'ORM m'avait créé mais dont on pouvait se passer).

Ce que je tire de cette expérience :

• Le modèle objet garde ma préférence car ce sont ces objets qui sont manipulés dans mon programme.
• Le schéma a également son importance pour des questions de performance et rapidité d'écriture. Exemple : à un moment, il me fallait les relations potentielles entre des objets (la différence entre les relations possibles et les relations effectives (comprenez enregistrées)) J'aurai très bien pu l'écrire avec du code mais avec un sgbdr, une requête SQL m'a mâché le travail (gain de temps et en efficacité)

J'ai donc mené les deux de front. L'idéal serait que l'outil automatique fasse bien le boulo de mapping mais ce n'est pas le cas (Je reconnais que je ne connais pas suffisamment l'ORM mais s'il faut passer 80% de mon temps pour comprendre sa mécanique pour réaliser les 20% les plus compliqué est-ce rentable)

Conclusion, je continue de raisonner en objet (ce modèle garde ma préférence et il n'est pas question que je fasse simplement une transposition de mes tables en classes) mais quand j'élabore mon modèle objet, je garde en mémoire un processus en arrière plan qui s'intitule "Comment implémenter cela dans le sgbd ?" Notez bien que si je choisissai un enregistrement par fichier, ce processus s'appelerai "Comment implémenter cela avec des fichiers ?" Je garde à l'esprit la partie physique, l'idéal pour moi étant d'avoir plusieurs solutions physiques à l'esprit (plusieurs implémentations) qui permettent de mieux conceptualiser (l'interface).

[benwit]

petite question concernant le model first et l'orm:
Imaginons que vous devez partager les donnees entre plusieurs applications distinctes sur different serveur, comment vous faites?

Si ce sont les applications qui sont sur differents serveurs, tu te fais une partie "Service de données" qui est utilisée par les autres applications. Le modèle est alors le modèle de la partie "Service de données".
Après, soit tu as une instance unique de cette partie qui échange les données avec les autres applications via socket/webservice.
Soit le code de cette partie (dans une librairie) est embarquée par les autres applications.
Je conseille également de découper : la spécification par interface et les implémentations (une pour un accès local et une pour un accès distant par exemple).
Exemple : MeteoDataService, MeteoDataLocalService, MeteoDataRemoteService

[mon_nom_est_personne]

mais dans ce cas, ca reviendrais pas a reinventer la roue ? je veux dire que ca ressemble tres fortement a cree un sgbd maison. Et je doute fort que ca a les meme performance qu'un access a un sgbdr classique.