Discussion :

[Promeneur]

Bonjour

Je voudrais avoir s’il est possible de sérialiser des objets Delphi Win32 qui ne descendent pas de TComponent. Des idées ou des pistes ?

Merci

[sjrd]

Il est possible, normalement, de sérialiser tout ce qui est TPersistent. Si la classe en question n'en est pas, soit c'est toi qui la développe et il faudra le faire ; soit ça n'est pas le cas et alors il faudra la sérialiser de l'extérieur.

[Promeneur]

Merci de ta réponse, sjrd. J'ai l'impression que le support de la sérialisation est une bonne raison de passer au C# ...

[sjrd]

Hem... Ne passe pas au C# pour la sérialisation. C'est un plus des langages .NET, certes. Mais .NET c'est tout une autre philosophie !

On profite de la sérialisation quand on utilise .NET... On ne passe pas à .NET pour avoir une sérialisation

[skywaukers]

bonjour,

qu'est-ce qui t'empêche de dériver ta classe de TPersistent ?

@++
Dany

[Promeneur]

On profite de la sérialisation quand on utilise .NET... On ne passe pas à .NET pour avoir une sérialisation

Oui, j’ai un peu exagéré ma formulation . De fait, pour l’instant, un prototype de la partie la plus complexe de l’application tourne, sans faire appel à la sérialisation, et développé avec Delphi Win32. mais ce n’est qu’un prototype, pour valider une idée fonctionnelle. Le développement réel n’a pas commencé. Le framework DOT.NET me plait beaucoup, et j’ai l’intime conviction que c’est une solution d’avenir, c’est la vraie raison pour laquelle j’envisage sérieusement le développement du projet en C# plutôt qu’en Win32.

qu'est-ce qui t'empêche de dériver ta classe de TPersistent ?

Si l’on reste en dev win32, c’est une piste que j’explorerai. Toutefois, l’utilisation de TPersistent ne me paraît pas claire, les livres que j’ai dessus et les ressources trouvées sur le Net ne sont pas très explicites. Autant il semble facile de sérialiser des composants, autant je suis dans le flou pour des classes qui n’en sont pas.

Le but est de passer des objets entre applications, sur des PC distants.

[Sub0]

On en a un peu discuté dans ce sujet il me semble :
http://www.developpez.net/forums/sho...=216030&page=3

[Promeneur]

On en a un peu discuté dans ce sujet il me semble :
http://www.developpez.net/forums/sho...=216030&page=3

Oui, j'avais lu ce sujet en faisant une recherche. Mais si je me souviens bien, en fin de compte, les solutions proposées reposent sur des objets descendants de TComponent, pour utiliser les méthodes WriteComponent et ReadComponent. Je n'ai pas trouvé d'exemples clairs à propos de TPersistant, et dans un application ou la rapidité de transfert des données est un facteur crucial, cela ne me semble pas un bonne idée de créer des objets qui descendent de TComponent, inutilement lourd. L’idée est d’envoyer des objets métiers à saisir sur des clients de saisie, les objets apportant leurs propres règles de validation.

Ceci dit, je changerai peut-être d'avis. Cela pourrait peut-être rendre très génériques les logiciels clients de leur envoyer des composants avec l’interface homme machine, dans le flux, parce que comme cela ils n'auraient pas à connaître les détails de l'IHM pour un objet donné.

Je ne sais pas si je suis clair ^^ . On peut dire que j’ai deux choix : j’envoie vers les clients de saisie des objets métiers les plus légers possibles (de préférence pas hérités de TComponent), et chaque client de saisie est paramétré pour créer un objet d’interface (un composant visuel), pour chaque objet métier. L’avantage est les données à transmettre entre le contrôleur central et les clients de saisie sont allégées, donc de meilleures performances sur le réseau.

L’autre solution serait que le contrôleur crée lui-même le composant d’interface (composant visuel) à partir des objets métier, et envoie le nouvel objet (un objet métier contenu dans un composant visuel) sur le réseau, vers les logiciels de saisie. Hmm fo que j’y réfléchisse .

Merci de vos pistes de réflexion, en tout cas.

[Sub0]

La démo donnée par neilbgr semble être ce que tu recherches non ?

L’avantage est les données à transmettre entre le contrôleur central et les clients de saisie sont allégées, donc de meilleures performances sur le réseau.

Pour info, avec ma démo, j'obtiens des meilleurs résultats au niveau rapidité d'enregistrement et sauvegarde sur disque des données avec le format DFM qu'avec le format CSV, car il n'y a pas besoin de reformater les données pour recréer le contenu des objets, etc... Surtout que la différence de taille des fichiers n'est pas énorme non plus. Et puis il est toujours possible de zipper ces données pour optimiser le transfert; donc je ne suis pas certain qu'il y ait beaucoups de gain à envoyer uniquement les données saisies, surtout une fois ces données compressées...

Cela dit, mon objectif dans ce topic était différent : Pouvoir redéfinir rapidement le formulaire de saisie client en ayant pratiquement aucune ligne de code à retoucher. J'avais justement ajouté l'enregistrement au format CSV dans cette démo pour comparer les résultats. Cette "méthode" m'a surtout fait gagner pas mal de temps de développement, avec quelques avantages en suplément propre au DFM.

[Promeneur]

La démo donnée par neilbgr semble être ce que tu recherches non ?

Pour info, avec ma démo, ( ... )

Les deux démos, si je me souviens bien, font appel à des objets hérités de TComponent, pour pouvoir utiliser les méthodes WriteComponent et ReadComponent. Je ne suis pas sûr que ce soit une bonne solution de s'encombrer des méthodes et propriétés de la classe TComponent, dans mon cas.

J'ai cherche des démos avec TPersistent, sans TComponent, mais je n'en ai pas trouvé.