Quel était (ou serait) le raisonnement derrière la création de TdataSource en tant qu'intermédiaire entre les composants liés à des données et les TDatasets sous-jacents réels, plutôt que de se connecter directement aux TDatasets eux-mêmes?
Cela peut sembler une sorte de question stupide, mais je travaille sur un large ensemble de composants "Viewer Data", qui pointent vers un composant "Connecteur de données" commun; Et dans la conception de cet ensemble de composants, je me trouve référencer la structure du classique Delphi "Tdataset -> TdataSource -> Composante liée aux données" Configuration de la composante de données pour guidage. Dans mon ensemble de composants , je continue à vouloir de fusionner essentiellement la fonctionnalité des équivalents "TdataSource" et "Tdataset" en une seule classe. Cela me demandait de me demander quel était le raisonnement derrière les séparant en premier lieu.
5 Réponses :
Je ne sais pas si c'est exactement ce que l'équipe de Dev pensait, mais une manière dont il pourrait être utile, c'est pour modifier les ensembles de données. Disons que vous avez un tas de contrôles conscient de données, et ils sont tous liés à un ensemble de données, puis vous souhaitez passer à un autre. S'ils sont tous liés à travers un intermédiaire, tout ce que vous avez à faire est de changer la propriété de DataSource .DataSet au lieu de itération de toutes les commandes et de modifier leurs propriétés.
(Bien que vous puissiez toujours modifier un groupe de noms de champ, en fonction de la configuration des choses, cela pourrait donc ne pas être le meilleur exemple possible.)
Je pense que de sorte que les contrôles de mesure de données peuvent être attachés à différents ensembles de données, en modifiant simplement le jeu de données de type de données de données associé plutôt que de devoir changer de jeu de données de chaque contrôle.
Donc, vous pouvez modifier la base de données que vous utilisez simplement en changeant une source de données unique au lieu de charges de TDBebridits, TDBGrids, etc.
Dans les premières versions, il était presque impossible d'attacher des composants à différentes bases de données. Vous devez avoir une version de chaque composant pour la différencier de la base de données que vous vouliez utiliser et cela signifiait qu'une nouvelle base de données a eu du mal à venir. En séparant le lien de la source, vous pouvez passer facilement. La base de données peut également être une source programmée de temps d'exécution uniquement.
Si vous combinez ces deux deux, votre composant de base de données obtient une dépendance à l'infrastructure d'interface utilisateur spécifique que vous utilisez. Ce type de dépendances peut être correct dans votre propre programme, mais pas OK dans une API distribuée à beaucoup de développeurs.
Vous pouvez y réfléchir comme une sorte de motif de contrôleur de mode modèle.
Les données sont situées dans le jeu de données (le modèle) qui ne sait rien de qui les utilise et pour quoi.
Les composants de la DB axe fournissent différentes interfaces (les vues) de l'utilisateur à interagir avec ces données sans savoir qui les détient.
Le DataSource est le passage entre (le contrôleur) qui fournit la liaison et l'envoi de tout changement de données ou commande au modèle ou aux vues.
Ceci permet une liaison facile à un jeu de données différent sans toucher les vues, ou de modifier ou d'ajouter de nouvelles vues sans que l'ensemble de données ne soit tiré en charge d'eux.
Il s'agit de découplage et indirection .
et avec TdataSource, il y a deux types d'entre eux:
Étant donné que de nombreux composants peuvent pointer vers la même datasource, vous pouvez changer rapidement ce qui sous-jacent à Tdataset sous-jacent à utiliser simplement une propriété Tdatasource.DataSet.