Discussion :

[phplive]

Autrement dit le monde SQL impose sa vision au monde objet

l'inverse est possible comme avec ModelMaker sauf que si lors de la phase de conception on n'hésite pas à créer la structure de la base "vide", une fois la base en production j'ai pas trop envie de voir un colonne "disparaître" parce que j'ai malencontreusement supprimé un attribut dans mon schéma objet. Sur l'objet je peux toujours faire undo mais sur la base ?? Alors que si j'ai utilisé l'outils d'administration de la base c'est probable.

Par sécurité je préfère donc effectuer les modifs directement sur la base. Mais normalement les modifs de cette nature doivent être exceptionnelles hors phase de conception.

[chaplin]

l'inverse est possible comme avec ModelMaker

Va expliquer à un DBA, que ton ModelMaker dans Delphi va changer la structure de ses données d'un SI
(MainFraim) ou plusieurs dizaines d'utilisateurs travaillent dessus.
Déjà, InstantObjet doit supporter la base, sinon tu implémentes les classes à la mano par rapport
au connecteur spécifique, ce que j'avais fait juste pour faire un essai mais ensuite quand il faut
fournir le métadonnées de base de données, oubli.

Lorsqu'il faut travailler sur des millions de données, InstantObject est trop rigide parce qu'il impose
son modèle à la base de données de façon automatiques avec une clé GUID, c'est du fantasme.

Après c'est comme si tu dirais que va utilisé le coffre mécano 12 ans pour "bricolé" à son camion.

[phplive]

Va expliquer à un DBA, que ton ModelMaker dans Delphi va changer la structure de ses données d'un SI
(MainFraim) ou plusieurs dizaines d'utilisateurs travaillent dessus.

C'est pas "mon ModelMaker" je l'ai jamais utilisé : Et à vrai dire je suis même pas sûr qu'il fasse parti de Delphi 7

C'est bien pour ça que je préfère effectuer directement les modifs dans la base elle même. Et dans une base de test évidemment !
Le DBA ne peut quand même pas interdire aux développeurs d'apporter des modifs non plus. Pis bon comme je fais aussi office de DBA ben je suis souvent d'accord avec moi-même

De plus je suis plutôt un adapte du SQL natif que des générateurs de code

Lorsqu'il faut travailler sur des millions de données, InstantObject est trop rigide

J'ai dit exactement la même chose dans un post précédent mais pour tous les framework pas uniquement InstantObject

il impose son modèle à la base de données de façon automatiques avec une clé GUID

C'est bien pour ça que je n'utilise pas InstantObject je dois me connecter sur des sources qui n'ont pas de GUID mais des clés primaires parfois composées.
Donc mon existant m'impose sa loi

Cela dit avoir une clé unique pour chaque enregistrement du SI n'est pas si absurde que ça. (mais pas forcément un GUID à le noix façon Micro$oft )
D'ailleurs je soupçonne les SGBDR d'un gérer un en interne

utilisé le coffre mécano 12 ans pour "bricolé" à son camion.

Ha le Meccano ... l'un des jouets (?) les plus intelligents qu'on ait jamais inventé avec les Legos
t'as pas idée du nombre de produits soit disant high tech qui sont bricolés façon Meccano mais ... en pire Enfin plutôt si ! je sais c'est pas simple mais on doit faire avec j'utilise bien XP ... mais j'échappe à Vista enfin pour le moment

[Franck SORIANO]

J'ai eu une discussion avec un programmeur VB de formation scientifique qui me parlait de cette abérration
des commandes SQL en chaîne de charactère dont les erreurs ne sont pas détectées à la compilation
mais au moment ou le serveur interprête la commande.

abérration : c'est une question de point de vue. C'est dommage en effet de ne pas détecter les erreurs de syntaxe en amont, mais comment tu fais pour faire du SQL dynamique ?
Si tu veux que tes requêtes soient compilées pour détecter les erreurs de syntaxes avant l'exécution, il suffit de faire des procédures stockées...


Pour le reste, pour moi la base de données est quelque chose de bien trop important pour laisser un logiciel genre InstantObject ou Hibernate décider automatiquement de la structure des tables en fonction des objets que le dev veut manipuler dans son code.
Je considère qu'il faut définir le schéma de base de données qui va bien, adapté aux données qu'on doit gérer. En tenant compte des contraintes du SGBD et tout ce qu'il faut pour que la base puisse être fiable, robuste et performante.
Puis dans les applications, on définit les objets que l'on souhaite manipuler, avec la vision OO qui convient pour l'appli, indépendemment de la structure de la base de données sous-jacente.
Enfin, les frameworks de "persistance" (quelle belle abération, voilà un terme qui suggère que la base n'est la que pour rendre "persistant" les objets de l'appli), couche d'accès aux données, ou autre framework de mapping O/R sont la pour réconcilier les deux visions en faisant les traductions nécessaires pour passer de l'un à l'autre.

Je ne vois pas l'intérêt d'un framework qui part de l'une de ces deux visions pour s'imposer à l'autre.

[phplive]

Bjr

la base de données est quelque chose de bien trop important pour laisser un logiciel genre InstantObject ou Hibernate décider automatiquement de la structure des tables en fonction des objets que le dev veut manipuler dans son code

C'est clair. En général on ne touche plus à la structure de la base passé un certain stade de développement. Quelques ajustements sont possibles de temps en temps évidemment ne serait que pour intégrer les évolutions/nouveautés. Mais s'ils sont trop fréquent c'est qu'il y a un problème de fond quelque part

voilà un terme qui suggère que la base n'est la que pour rendre "persistant" les objets de l'appli

Exactement ! Voilà comment j'aimerais que ça fonctionne.
Mais pas forcément pour tous les objets possibles et immaginables, non, seulement pour ceux compatibles avec le schéma de la base.
Disons que si la base pouvait manipuler aussi bien les données sous forme de recordsets classiques que d'objets sans qu'on ait besoin d'ajouter quoique ce soit alors là

Avec une limite cependant : les objets se cantonnent uniquement à la manipulation des données donc LMD. (exception faite peut être des tables temporaires)

[chaplin]

C'est bien pour ça que je n'utilise pas InstantObject je dois me connecter sur des sources qui n'ont pas de GUID mais des clés primaires parfois composées.
Donc mon existant m'impose sa loi
...
Cela dit avoir une clé unique pour chaque enregistrement du SI n'est pas si absurde que ça. (mais pas forcément un GUID à le noix façon Micro$oft )
D'ailleurs je soupçonne les SGBDR d'un gérer un en interne

c'est juste phplive, la clé unique est un concept interessant. Mais entre la théorie et la réalité, l'existant prend trop souvent le pas sur les initiatives
car l'adoption d'une clé unique signifirai la remise totale du SGGBDR sauf si tu fais un système parallèle auto alimenté par des procédures stockées (ie statisques).

abérration : c'est une question de point de vue. C'est dommage en effet de ne pas détecter les erreurs de syntaxe en amont, mais comment tu fais pour faire du SQL dynamique ?
Si tu veux que tes requêtes soient compilées pour détecter les erreurs de syntaxes avant l'exécution, il suffit de faire des procédures stockées...

L'algèbre relationnel est un outil magique dont on ne peu pas se passer, une drogue que la modèle objet ne fournit pas sauf LINQ.
Donc il faut faire tous ces ponts/interfaces entre 2 langages.
Pour cette souplesse d'utilisation, on accepte de travailler en chaîne de charactère. C'est le vice du système !

Disons que si la base pouvait manipuler aussi bien les données sous forme de recordsets classiques que d'objets sans qu'on ait besoin d'ajouter quoique ce soit alors là

C'est là ou je voulais en venir phplive . Toute la dificulté serait de faire communiquer deux langages de façon simple sans faire le saut de l'un à l'autre
par des " où '. Je reste toujours sur l'idée d'utiliser des interfaces car c'est le seul moyen pour faire communiquer deux mondes par définition.
Pour cela il faudrait une API spécifique pour une communication de type objet.
Un LINQ côte SGBDR

autre framework de mapping O/R sont la pour réconcilier les deux visions en faisant les traductions nécessaires pour passer de l'un à l'autre

réconcilier, très juste Franck SORIANO, tu as utiliser le bon terme. Pour le reste, je suis du même avis.

[phplive]

Pour l'instant j'en suis encore à ce stade pour un simple enregistrement ...

Code :

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

1
2
3
4
5
6
7
+--------------------------+  +---------------------+
| +-------+    +---------+ |  | +-----+    +------+ | 
| |       |--->|         |----->| SQL |--->|      | |
| | OBJET |    | MAPPING | |  | +-----+    | SGBD | |
| |       |<---|         |<----------------|      | |
| +-------+    +---------+ |  |            +------+ |
+--------------------------+  +---------------------+

[chaplin]

Par hasard, je suis tombé sur ce lien, peut-il te servir à quelque chose, Phlive ?

http://sjrd.developpez.com/sepi/

J'ai repris un extrait de la présentation du projet:

La principale différence d'avec les moteurs de script existant, tels que Pascal Script de RemObjects Software ou Scripter Studio de TMS Software,
est que Sepi permet non seulement aux scripts d'instancier et de manipuler des objets de classes Delphi natives, mais aussi et surtout de créer
leurs propres classes.

[phplive]

Bsr

Hum ça doit être pointu comme code pour générer des classes à la volée

Pour mes objets métiers qui sont hautement spécialisés je ne vois pas directement d'application mais on ne sait jamais.

Pour le moment je créé mes classes de façons statique et je mappe mes classes sur chaque table du SGBD : une unité par table. Je dis pas que j'écrirais pas à petit outils Delphi qui générera une classe de base à partir d'une table à un moment ou à un autre mais pour le moment c'est suffisant.

La partie MAPPING est presque terminée j'ai plus qu'à écrire le générateur de SQL et mes objets vont enfin pourvoir se charger automatiquement via IObject.Load(...) tout en me laissant la possibilité d'envoyer du SQL directement au serveur.

Je pensais aussi vérifier la syntaxe SQL avant de l'envoyer au serveur : rien qu'en convertissant la notation infixe en NPI c'est dingue le nombre d'erreur qu'on peut détecter : parenthèse manquante, fct invalide ou mal utilisée, paramètre manquant ou en trop ... Mais bon je garde ça pour plus tard pour l'instant c'est le serveur SQL qui teste les erreurs

[PRioux]

Que pensez-vous de ce componsant http://www.macrobject.com.

[ShaiLeTroll]

Merci PRioux si tu parle de Macrobject DObject (ben tu ne donne que le site sans précision) c'est effectivement l'un des nombreux concurrents à InstantObjects ou ECO.NET

Par contre, qui l'a essayé ?
leur exemple commence directement par l'utilisation d'une liste (j'aurais pu le confondre avec ma propre couche ), mais en général, cela ne supporte jamais correctement la volumétrie ... d'ailleurs, on abandonne rapidement l'idée de précharger les objets, ...

[PRioux]

Merci de votre réponse. Effectivement je parlais de DObject, désolé pour cette omission. À ce je comprends pour avoir fait quelques tests ce framework supporte le lazy load ce qui permet de charger les objets uniquement au besoin et selon leurs utilisations. Pour avoir regarder InstantObject je vois pas comment la persistance d'objets peut être utilise surtout dont la façon dont le contenue de ces objets sont garder dans le database. Ce n'est vraiment pas normalisé. Cette façon de faire à long terme sera très pénible. Je ne vois vraiment aucun avantage à prendre cette direction. Malheureusment avec Delphi les options sont un peu limiter car je n'ai rien trouvé à date qui est vraiment intéressant. Quand à ECO.Net ça me semble bien mais pour .NET seulement alors ce n'est d'aucune utilité pour moi actuellement. Ce que je trouvais bien avec DObject est de centraliser les règles d'affaires et d'ainsi simplifier la réutilisation. Après une réponse de DObject, il n'ont aucun plan pour rendre les objets data aware. Ce qui aurait été une excellente chose à mon avis.

[ShaiLeTroll]

InstantObject, ah tu as donc testé, moi je n'ai jamais pris le temps, j'ai regardé le code, et vu qu'il n'y avait pas de IsNull sur les Attributs, j'ai donc pas cherché plus loin ...

Ah, oui, lien les composants visuels avec des objets, on a plusieurs méthodes dans ma boite, un truc qui fonctionne via le nommage du champ (genre cbx_NomDuChamp__NomDuDico, ... uzinagaz) ou un Mappeur que l'on pose sur la DFM avec lequel on lie un champ d'un objet et un control (un peu comme l'éditeur de colonne des grilles)

centraliser les règles d'affaires

Oh comme tu parles bien, lol, là où je bosse, le SQL il traine ci et là, certaines applis doivent avoir la même requête écrite de 50 façon différente à un bon millier d'endroit différent (je laisse imaginer un passage de MySQL sur Windows pour un MySQL sur Linux qui est sensible à la casse des noms de tables, rien que ça c'est pas normé non plus ! alors des "règles d'affaires", ... je dirais des règles de comment bien faire avant )

[PRioux]

Afin de répondre à ce commentaire émis un peu plus haut par 'phplive'...

"Pour le moment je créé mes classes de façons statique et je mappe mes classes sur chaque table du SGBD : une unité par table."

DObject fait exactement ça et il gère les insert, update et delete en plus.
Il permet un lazy load sur les tables enfants par exemple (chargé si accédé) ou sur un champ (champ blob par exemple). Il garde aussi le lien avec les tables enfants.

Si des champs sont ajoutés, il faut simplement ré-exécuter l'outil de génération sans plus. Toute cette partie est généré automatiquement et les déclarations sont ajouté au .pas

Le mapping se fait tout seule à partir du shémas et il reste qu'à mettre le code spécifique (règles d'affaires). Ont peut par exemple faire un override de la méthode save afin de faire certaines validations et appeler le inherited save pour poursuivre la sauvegarde. Je crois que vous devriez regarder ce genre outils au lieu de créer toute vos classes manuellement. Pensez à la maj par la suite. Mais bon c'est un commentaire bien personnel à vous de juger.

Pour ma part nous avons aussi du SQL à différentes place mais il n'est pas dans le code Delphi directement. Il est dans des fichier .RES et join aux .EXE
C'est mieux mais pas l'idéale. Ont doit vivre avec la passé. Il est cependant jamais trop tard pour apporter des améliorations!

[ShaiLeTroll]

Je crois que vous devriez regarder ce genre outils au lieu de créer toute vos classes manuellement.

C'est tellement moins fun, phplive investi du temps pour sa couche, qui est plus un gros laboratoire technologique qu'un réel outil (il s'est lancé dans le respect des Design Patterns et il a des soucis qui découlent directement dans leurs utilisations mais que je n'ai pas parce que je me suis concentré sur la facilité d'utilisation et non sur normalisation du code) ... en tout cas c'est comme ça que le perçoit, parce qu'ayant fait aussi une couche, en fait, j'ai repris un applicatif déjà existant avec un autre modèle OR, qui était limité, relation n-n non supporté, pas de LazyLoading, pas de gestion du null, ... j'ai tout simplement réécrit à ma façon, avec le recul, je me suis bien éclaté, maintenant, il aurait été plus simple, plus rapide d'écrire tout en SQL à la sauvage (avec un minimum d'objet pour structurer le code) ... ou d'acheter un Lib, mais on a déjà trop, je ne serais jamais partisant pour me rendre dépendant encore d'un autre truc ...

[phplive]

Bsr

DObject fait exactement ça et il gère les insert, update et delete en plus.

A ce stade de développement on peut dire que mon OPF s'approche de ce que fait certainement DObject Sauf que ma version est par définition forcément plus flexible (pour moi s'entend pas pour un autre développeur j'en conviens) même si elle est moins aboutie ...
La dernière modif en date : le clonage des objets dès que je les modifie (j'ai hésité avec le memento pattern mais je ne regrette finalement pas mon choix voir mon post
Modif d'un objet persistant : clonage ou memento ?

C'est tellement moins fun, phplive investi du temps pour sa couche, qui est plus un gros laboratoire technologique qu'un réel outil

Rien de tel que de bosser sur un projet qu'on est pas tenu de mettre un jour en prod pour progresser : hé là y'a pas photo ! Objet, héritage, interface, allocation mémoire, API après avoir fouiner dans toutes ces notions je sais bcp mieux programmer sous Delphi 7 ! Surtout lorsque je compare à ce que j'écrivais avant ... Par ex aujourd'hui je ne mets pas en prod un prog tant que FastMM me sort une erreur de memory leak

Et au fait pour répondre à ma question : Creation d'objets "par lots" ?
J'ai ma réponse ! Delphi optimise déjà tout ce qu'il est possible de faire : on ne gagne quasiment rien à essayer de faire mieux que son memory manager ou celui de FastMM A la limite le seul truc qui peut faire gagner du temps c'est un pool d'objets et encore faut voir ...

Le mapping se fait tout seule à partir du shémas et il reste qu'à mettre le code spécifique (règles d'affaires). Ont peut par exemple faire un override de la méthode save afin de faire certaines validations et appeler le inherited save pour poursuivre la sauvegarde. Je crois que vous devriez regarder ce genre outils au lieu de créer toute vos classes manuellement.

Il est clair qu'un outils gérant le mapping en lisant directement la structure des tables fait gagné un temps précieux Maintenant faire un générateur automatique de classe pour mon OPF à partir du schéma d'une base est facile donc je ne m'inquiète pas vraiment de ce côté là. Par contre rendre les composants de la VCL OPFAware comme dirait JCVD c'est autre chose !

acheter une Lib

on y est ! Utiliser une lib toute faite : why not ? Le hic c'est qu'au départ ça semble correspondre à ce qu'on cherche et plus on avance et plus on perd de temps parce que c'est soit mal documenté, soit certaines fonctionnalités sont absentes (attendez la prochaine release vous verrez ! Ben voyons ), soit ce n'est tout simplement pas possible de faire tel truc avec telle lib ... seulement ça personne ne vous le dit ! (sauf ici bien sûr )

il aurait été plus simple, plus rapide d'écrire tout en SQL à la sauvage

Comment se fait-il que tous les développeurs maîtrisent parfaitement cette technique alors que je ne pense pas qu'elle soit enseignée ?

Oh comme tu parles bien, lol, là où je bosse, le SQL il traine ci et là, certaines applis doivent avoir la même requête écrite de 50 façon différente à un bon millier d'endroit différent (je laisse imaginer un passage de MySQL sur Windows pour un MySQL sur Linux qui est sensible à la casse des noms de tables, rien que ça c'est pas normé non plus !

Tout pareil ! C'est pas possible ça ! Et après les utilisateurs se demandent encore pourquoi ça plante ! les pauvres s'ils savaient ...
Ce sont les même qui croient que ma devise n'est qu'une qu'une catchphrase extraite d'une série TV mais ils ont tort : les gens ne sont pas prêts; ils ne doivent pas savoir