Discussion :

[Jean-Jacques Engels]

Bonjour,

Voici mon cas d'école : Je crée un objet "Personne" qui va chercher ses données dans une table "Personne". Les propriétés publiques de mon objet contiennent donc les valeurs des champs de la table Personne.

Habituellement, pour éditer les champs d'une table, on dispose d'une série de composants d'accès aux données tels que TDatasource, contrôles visuels orientés base de données, etc. Dès qu'on place un objet métier devant les données, ces composants ne sont plus accessibles (sauf erreur ou compétence limitée de ma part).

J'aurais souhaité savoir quelle solution vous préconisez pour permettre l'édition à l'écran des propriétés de mon objet (Delphi XE).

Merci.



JJE

[ShaiLeTroll]

ton objet "personne" est une classe héritant de TObject ou TPersistent, que tu remplis manuellement ou par RTTI depuis une DB ?
une couche métier avec plus ou moins de persistance

As-tu regarder les LiveBindings ?
Pour un ancien projet (autre société), j'avais dévéloppé un système (nommé MappeurUI intégré comme ComponentEditor dans l'IDE) pour gérer des TEdit, TCheckBox avec des objets persistants, avec les RTTI, ce système pouvait même gérer les DB Controls en utilisant les mêmes données de configuration

Gérer la valeur nulle a été un calvaire !
J'ai abandonné l'idée d'isoler mes objets métiers totalement des DB Aware !
Je privilégie une technique permettant d'avoir la rigueur de l'objet mais la facilité du DataSource !

Plusieurs solutions, en voici une que j'utilise actuellement

J'ai déjà exposé mes idées farfelues ici ou là :
Copier les données d'un objet dans un autre
Comment utiliser les composants de données et faire de la programmation orientée objet
Création d'objets "par lots"

Pour mes projets actuels de type industriel, j'ai des objets orientés batch (type 1) et d'autres orientés saisies (type 2)
C'est un peu particulier

l'objet "métier" (type 2) a une propriété DataSet (masqué en protected)
Il a souvent une propriété DataSource (promu en public)

Code :

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

1
2
3
4
5
6
7
8
class TSygalORPersistent : public TPersistent
{
...
  // Propriétés Protégées pouvant être promues en Propriétés Publiques mais pas Publiées !
  __property TDataSource* DataSource = {read=FDataSource, write=SetDataSource};
  __property TDataSet* DataSet = {read=FDataSet, write=SetDataSet}; // Propriété qui théoriquement devrait toujours rester interne, le DataSource devrait être le seul moyen d'accès externe que ce soit pour définir un DataSet Extérieure ou pour s'accrocher à un DataSet Interne
  __property AnsiString TableName = {read=GetTableName};
...

};


Le property vont lire et écrire dans ce DataSet (dans on cas un TClientDataSet ou TSimpleDataSet en mode Edit ou Append)

Ma méthode Save utilise les RTTI pour générer le SQL
La Méthode Save va évidemment contrôler les Données AVANT de générer le SQL (et l'exécuter)

le Save REMPLACE le Post, ce dernier est inutile sur le TClientDataSet (il va juste modifier la mémoire), et pas plus sur le TSimpleDataSet tant que l'on utilise pas ApplyUpdates(), ce que je ne fais pas, j'ai suivi la méthode de mon employeur actuel

Cela fonctionne pour un objet lisant UNE ligne
la propriété DataSource permet accéder au DataSet interne de l'objet ainsi on peut lui connecter des TDBEdit, TDBCheckBox ...

Cela fonctionne pour un objet lisant PLUSIEURS ligne (couplé avec une TDBGrid), cette fois-ci le DataSource fourni un DataSet externe (fourni par un TSQLQuery, ça lié à du code existant dans la lib interne que j'ai conservé dans l'état)

Ainsi dans le code tu manipules TOUJOURS l'objet qui suit le déplacement dans le TDBGrid

En général, mon objet métier de base (type 1), est en lecture seule, il contient des méthodes métiers pour mettre à jour certains éléments (en généralement des états)
les propriétés publiées sont des valeurs qui ne bougent pas comme les clés primaires, clés etrangères (ça en fait, il y a souvent une propriété publique de type TShaiORPersistentRelation) et d'autres données informatives

l'objet hérité (type 2) qui lui ajoute les possibilités d'écriture (et l'accès à la propriété DataSource) pour modifier les valeurs permanentes comme ses libellés ou clé étrangère, les valeurs que maîtrise l'utilisateur, pour une caméra, c'est son IP ou son Canal sur un DVR, son mot de passe, login, sa résolution, des éléments fixes dans le temps...

les autres données concernent des états comme "pingable", connecté ou pas, erreur ou pas, flux ou pas ... sont lus au démarrage, au chargement de l'objet par le serveur mais n'ont quasiment aucune valeur car obsolète, elles seront très rapidement remplacer par les états actuels.

Evidemment le pendant de Save c'est Load
selon son implémentation, l'objet contient soit
- des membres privés initialisés par RTTI (type 1)
- un ClientDataSet (type 2)

type 1, ces objets ne sont pas prévus pour être afficher, faut le faire à la main, ou alors créer un objet héritant de celui-ci pour qu'il gère un CDS interne (mes accesseurs de propriétés sont écrits en prévision de cela avec des accesseurs génériques SetIntegerProp, SetBooleanProp...)

type 2, souvent c'est juste l'éditeur d'un objet type (1)

les objet type (1) sont utilisés massivement dans des applications serveurs, inutile de fournir un code de modification que je ne sera jamais utilisé

les objets type (2) sont utilisés pour configurer les objets type (1)
cela donne en pratique
TShaiCameraCustom = class(TShaiPersistentObject) - type (1)
TShaiCamera = class(TShaiCameraCustom) - type (1) avec plus de propriétés utilisés dans les serveurs
TShaiCameraMaterielEditor = class(TShaiCameraCustom) - type (2)

TShaiCamera est utilisé côté serveur pour les accès massifs ou dans le moniteur video
TShaiCameraMaterielEditor est utilisé uniquement dans le programme de configuration

toi, il est fort possible que tu n'aies que des objets type 2

[Jean-Jacques Engels]

Merci ShaiLeTroll.

Je découvre ton message à l'instant. Je vais le lire attentivement.



JJE