Houlà je voulais juste dire que au départ j'utilise certaines structures et que ce n'est souvent qu'après par hasard que je découvre que le principe existe déjà et qu'il s'appelle par ex un design pattern
On est dans le débat 
Hélas tu as raison car les documentations te présentent souvent ces algos de façon beaucoup trop généraliste et soulèvent généralement plus de questions qu'elles n'apportent de réponses. Mon impression en lisant certaine doc : bon ok c'est bien mais comment je l'utilise en pratique ? Comment je l'adapte à mon problème donné ? En fait je pense que c'est à ce moment que l'expérience entre en jeu chose qu'aucune doc au monde ne pourra jamais fournir.
Nous somme d'accord 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| Enreg[0]
[Fournisseur]
[Commande A]
[Article X]
Enreg[1]
[Fournisseur]
[Commande A]
[Article Y]
Enreg[2]
[Fournisseur]
[Commande B]
[Article W]
Enreg[3]
[Fournisseur]
[Commande B]
[Article Y]
Enreg[4]
[Fournisseur]
[Commande B]
[Article Z]
Enreg[5]
[Fournisseur]
[Commande C]
[Article X]
Enreg[6]
[Fournisseur]
[Commande C]
[Article Z] |
Oui c'est tout à fait comme cela que je l'envisageait, mais pour réctifié mon propos sur le TDataset,
ce serait davantage d'avoir une classe qui encapsule à la fois :
- un comportement de TDataset (property) pour le publié vis à vis d'un datasource
- et le comportement d'un objet, voir la classe de l'objet qui intégre le Dataset.
Toute la difficulté est de trouver cette frontière entre le monde objet et le monde relationnel.
Parfois on voudrait l'un, parfois l'autre, parfois les 2 à la fois.
Si on affiche les données dans un DBGrid et là j'élargit mon raisonnement à tous les composants tiers qui existent sur le marché,
il serait dommage de s'en privé.
En revanche, lorsqu'il s'agit de s'attaquer à la partie métier, c'est vrai que la vue objet est bien plus pratique.
Mais si on peut faire les 2 à la fois, c'est top parce que chacun a ses avantages et ses inconvénients.
C'est pour celà que j'évoquais le Flyweight pattern, car il renvoit l'instance d'une classe. Il biaise la "vue" objet en faisant
croire qu'il y a un objet par enregistrement. Je tiens ce raisonnement uniquement pour des raisons de performance.
Il n'y a rien de plus emmerdant que d'écrire:
MyFacture.FiedByNAme('NOM_CLIENT').AsString := MyClient.FiedByNAme('NOM_CLIENT').AsString ;
au lieu de:
MyFacture.Nom_Client := MyClient.Nom_Client;
c'est d'une part plus lisible et plus métier.
Peut être que je suis à coté de la plaque 
) c'est de plus en plus facile de coder from scratch ...
Mais on consacre tellement de temps à essayer de comprendre le pourquoi du comment qu'on finit par se poser des questions : ça vaut le coup d'insister ou vaut-il mieux le développer soi même ?
)
Répondre avec citation
Envoyé par chaplin
on
Partager