Discussion :

[tiboleo]

Je développe en C#
Mon système est déja conceptualisé (MCD et autres...)
Je voudrait utiliser l'avantage de l'objet pour développer.

Globalement, je voudrais faire l'équivalent en classe de chacune de mes tables du SGBD.

Si je me résume:

J'ai mon SGBD
Dans l'appli, je peux déclarer des classes (exemple, j'ai une table OBJECTIF, je peux créer une Classe CObjectif) --> el // j'aurais donc une modélisation UML
Tous les objets que j'instancie peuevnt être insérés dans mon SGBD (INSERT, UPDATE,...) grâce à des méthodes de selection et de mise à jour vers ma base.

Est-ce correct?

[vanquish]

Oui et non.

Développer des classes de table, ne serait-ce que pour le trafert variables membres->SGBD et SGBD->variables membres est une bonne idée.
Mais fait quelque chose de générique à la base
Déjà il te faut donc un objet générique CChamps présentant comme propriétés : nom du champ, valeur actuelle, type etc..

Il te faut ensuite une classe CTableGenerique que du dérivera pour chaque table. Cet objet aura une collection (tableaux, listes) de sous-objet CChamps

Dans le constructeur de chaque table dérivant de CTableGenerique tu fera une construction tu type

AjouterChamps('nom_champ1' , myINT , valeur_defaut );
AjouterChamps('nom_champ2' , mySTR , '' );
ClePrimaire := 'nom_champ1';
etc...

La classe CTableGenerique présantant comme méthode des chose comme ContruireInsertString, qui en fonction de la liste de champs présent dans les classe enfant, sera capable de construite de façon générique la requête INSERT.

CTableGenerique devrait aussi avoir une fonction te permettant d'accéder à un champ ce qui te permettra des contruction type ADO/DAO :

MaTable.Champs('code').Valeur = 7 ;
ou
MonCode = MaTable.Champs('code').Valeur ;

En utilisant ce type de construction dès ton objet racine, tu t'éviteras beacoup de code redonnant d'une table à l'autre.

J'ai une construction de ce type et mes objets tables n'ont qu'une seule méthode : le constructeur qui défini la liste des champs. Tout le reste est dans la classe générique de base.

Mais surtout, au dessus de tes classes de table il te faudra développer des objets "métier", car il est rare qu'une table se suffise à elle même.

Il te faut donc gérer des objets de plus haut niveau.
Par exemple si tu a une table facture et ligne_facture, en plus des objet de bas niveau, il te faudra une classe CFacture qui contendra une liste d'objet CLigneFacture

Avec une instyruction du type
MaFacture.Charger( CodeFacture )
qu te chargera l'entête de la facture, mais aussi toutes les lignes.
Le programme appelant pourrat ensuite lire les ligne avec une syntaxe du type

MaFacture.Ligne(i).code_article

Ainsi ton programme principal n'a pas à ce soucier de la structure exacte des tables, ni du SGBD sur lequel tu te base.

Si le SGBD change, tu adapte des classe de bas niveau.
Si la logique métier change, tu adaptes tes objets métiers.
Le programme principal se détache donc des mécanismes de plus bas niveau.

[Maximil ian]

Moi je dirais pourquoi pas.
Ca peut te simplifier la vie mais ca peut aussi se révéler très lourd à l'usage.
J'imagine que tu as déjà plein de classes qui servent à ton application elle-même. Rajoute à ça autant de classes que de tables dans la BD, ça devient un sacré fouillis... en plus de ralentir ton programme.

En revanche, j'aurais plutôt vu : les tables de la base de données correspondent aux classes utilisées dans l'appli.

[tontonplaisir]

Salut à tous!
Je m'aprêtais à déposer un message sur le forum quand j'ai lu celui ci et il correspond presque exactement à ma problématique.
Ben voilà je suis débutant et on me demande justement d'écrire un code générique en c#.
J'avoue que je n'ai pas bien compris l'utilité de ce code et je ne fais pas encore le lien avec ma base (sql server).
Là j'en suis encore au design de ma base avec powerdesigner. Est ce que vous pourriez m'expliquer le lien entre ce code générique en question et ma base de données? Quelle est l'utilité de ce code? Comment l'exploiter dans le code de l'application et comment le créer (avec des exemples si possible)?

Merci

[SQLpro]

C'est très facile à faire si le SGBDR dispose de procédures stockées.

1) une procédure READ par objet qui renvoie une table

2) une procédure WRITE par objet (insert ou update)

3) une procédure DELETE par objet

Et voila.

Sinon il existe des produits de mapping relationnel objet qui se comportent comme des middleware.
Exemple infobjects:
http://www.infobjects.com/default/fr/html/Home.html

A +

[Bruno75]

Ce sujet tombe bien.
SQLPro, dans tes cours tu parles de la méthode des méta données. Deux questions :

- Tu cast toutes tes données en String : Ca ralentit pas à mort ??
- Est-ce possible avec Access ?

[Edit]
Heureusement pour moi, j'ai que des doubles pour l'instant
[Edit]

[Bruno75]

Pour répondre à Maximilian.
Une table pour chaque classe ca correspond pas forcément alors que la méthode évoquée par vanquish va te permettre de sauver n'importe quel objet. En plus tu peux préparer tes requêtes au lancement de ton rogramme pour chaque classe donc je ne pense pas que ca ralentisse.
En plus si tu veux faire une sauvegarde massive d'objets =>

Tu sauves tous tes objets dans UN SEUL CSV et blam dans ta base. SI t'as autant de tables que d'objets, amuses toi.
Le chargement va aussi être simplifié.

[Edit]
Putain je suis en train de réinventer la roue et ca me fait chier mais bon je me suis coincé tout seul.
[/Edit]

[tontonplaisir]

Personne ne peut m'expliquer pourquoi on écrit un code générique et quelques guidelines pour le faire? On dirait même pas que j'ai laissé un message, il a purement été ignoré. Ma question est elle bête?

[Bruno75]

Lol, sorry.

Soit c'est un juste un besoin => ne réinventes pas la roue comme moi, diriges toi vers une solution existente. Parce que le risque que j'ai c'est de faire une roue carrée. Si tu prends une solution existente t'auras plein de docs et d'exemples. Par exemple jette un coup d'oeil sur le lien filé par SQL Pro, y a une très bonne explication des tenants et des aboutissants. C'est très général et très clair.

Soit c'est un exercice auquel cas tu dois vraiment écrire le code. Ben là j'ai pas le temps.

[Maximil ian]

Une table pour chaque classe ca correspond pas forcément alors que la méthode évoquée par vanquish va te permettre de sauver n'importe quel objet.

Euh, sauver n'importe quel objet c'est justement ce que fait la méthode "une table pour chaque classe". Ca permet d'aller chercher ton objet dans la base au début du programme et de l'instancier exactement dans le même état où il était auparavant.

En plus tu peux préparer tes requêtes au lancement de ton rogramme pour chaque classe donc je ne pense pas que ca ralentisse

A mon avis ça ralentit forcément.
Pour reprendre l'exemple de vanquish : au lieu de faire simplement une requete sur les lignes associées à la facture et de mettre le résultat dans les données membres de l'objet facture (1 instanciation), tu dois créer un objet par ligne de facture, un objet pour la facture de la base de données, et un objet pour la facture qui va réellement servir dans le programme (N+2 instanciations).
C'est plus long à coder mais aussi plus long à l'exécution.

[tontonplaisir]

Merci ploumploum! Je vais voir le lien filé par SQLPro et je t'envoie un message si je m'en sors pas. Merci! :o

[Bruno75]

En fait après relecture du post de vanquish, j'avais en tête plutôt autre chose. La coincidence fait que je bosse en ce moment sur une technique générique de traduction objet / relationnel.

En gros une table pour tous les objets.
CREATE TABLE OBJETS_INSTANCES(
ROW_ID // clé primaire mais on s'en fout ici
OBJET_ID, // l'objet
SS_CLASSE_ORDER, // le numéro de la sous classe
PROPERTY_ORDER, // le numéro de la propriété dans la sous classe
VALUE, // la valeur de la propriété(en considérant qu'il n'y a que des double pour l'instant mais SQL Pro propose de tout mettre dans des strings et de faire des CAST mais là je m'y connais pas trop)
[Edit]
Pas que des doubles, des truc qui tiennent dans des doubles à savoir, integer, objets(par leur id), ensembles finis(integer), ... A vrai dire il manque que les str mais pour l'instant j'en ai pas besoin.
[/Edit]

Donc pour charger un objet :
SELECT * FROM OBJETS_INSTANCES WHERE OBJET_ID = 234
ORDER BY SS_CLASSE_ORDER ASC, PROPERTY_ORDER ASC

Pas d'objets tables en fait
ET ensuite pour charger dans chaque sous classe

Code :

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

1
2
3
4
5
6
7
8
9
 
procedure Load(DataSet)
begin 
   inherited Load(DataSet)
  property := DataSet.Value
  DataSet.Next
  property := DataSet.Value
  ...
end;

Avec des bons index, et en remarquant que tu peux utiliser un curseur serveur avec adOpenForwardOnly, à mon avis c'est assez rapide et en plus très générique.

Effectivement, tu peux aussi faire une table par objets mais je trouve ca un peu moins générique.
Par exemple, dans mon cas, je peux générer sans difficulté un flux d'objets et tout recharger en récupérant ce flux sans aucune difficulté.
Ce flux je peux le stocker dans un fichier, du xml, etc...

Dans ton cas ca va être un peu plus galère me semble-t-il mais peut-être me trompes-je, je suis loin d'être un expert.

[Edit]
L'inconvénient, c'est que ta base doit pouvoir gérer la taille de la table si tu as beaucoup d'objets
[/Edit]

[Bruno75]

Bon, désolé. Des fois on ferai mieux de la fermer. En fait après qqs lectures je suis tombé sur des articles d'un certain Scott Ambler.
http://www.agiledata.org/essays/mappingObjects.html

En fait il propose 4 méthodes
- 1 table parhiérachie
- 1 table par classe concrète
- 1 table par classe
- 1 modèle générique

Chacun ayant ses avantages et ses inconvénients.

Son site regorge d'info sur le mapping et peut être complété par la lecture de ses ouvrages.

[Bruno75]

son site personnel (http://www.ambysoft.com/) est bourré d'infos sur la persistence. C'est un spécialiste de la persistence d'une part, et des méthodes agiles d'autre part.

Tout est en anglais bien sûr