«Remplacer les composants non visuels par du code» est une technique d'optimisation éprouvée dans Delphi 7. Principalement en ce qui concerne l'accès aux bases de données.Remplacement des composants non visuels par le code
Il ne s'agit pas d'être un composant ou un composant. En ce qui concerne l'accès à la base de données, BDE est extrêmement lent, donc le changer pour sth else est un bon choix. D'ailleurs, l'optimisation ne concerne pas les «techniques éprouvées». Il s'agit d'identifier un problème et de le résoudre. Si le problème est d'avoir un accès lent à la base de données, c'est ce que vous devez changer.
En ce qui concerne l'accès à la base de données J'utilise des objets ado et non bde parce que je suis plus familier avec ado. –
Je ne vois pas comment un ensemble de données basé sur un formulaire/requête/table/etc., Serait plus rapide ou plus lent que celui créé dans le code. Cependant, j'aime les mettre dans le code car c'est plus facile à maintenir. J'ai vu des écrans avec SQL intégré dans un composant, puis il est remplacé dans le code. Ensuite, je dois arrêter et étudier pour déterminer quel SQL est réellement en vigueur. Parfois, le SQL dans le formulaire est bon, parfois il est utilisé pendant un certain temps, puis tronqué par le code, parfois il n'est jamais actif et le SQL est écrasé dans le formcreate. Donc, je dois déterminer si c'est par conception, ou tout simplement des restes bâclés. En outre, il est facile de manquer les modifications SQL dans les révisions de code si elles sont dans le .DFM et pas le .PAS. c'est-à-dire que je ne regarde pas toujours le format .DFM parce que je ne suis pas intéressé par la modification d'une légende d'étiquette ou par le déplacement d'un bouton. Donc, bien que ce soit sympa pour le prototypage, quand il s'agit de code de production, il vaut mieux avoir toute la logique de votre base de données (définitions SQL, table et champ) dans le fichier .pas. Mise à jour: J'ai finalement donné CnPack un essai. Parmi les douzaines de goodies, il y a un outil génial appelé "convertir les composants sélectionnés en code". Assistant de conception de formulaire | Plus ... | Convertir les composants sélectionnés en code. Il fait tout pour vous.
C'est ce que je prévois de faire. La base de code sur laquelle je travaille actuellement est héritée et non ce que j'ai créé. Donc, je pense qu'il faudra du temps pour déplacer toute la logique sql du fichier .dfm dans le fichier .pas –
@Vinayek - vous ne serez pas désolé. Vérifiez également que toutes les tables, tous les connecteurs de base de données, toutes les sessions, etc. sont désactivés. Si vous en trouvez qui sont actifs, soyez très prudent dans le code pour vous assurer d'ouvrir les connexions vous-même. c'est-à-dire que vous pouvez avoir des formulaires qui "ont de la chance" parce que la base de données réside réellement là où l'auteur original pensait que ce serait. –
Merci pour le conseil. Je viens de commencer à réécrire la partie d'accès aux données du code. –
Le site Web que vous citez parle de remplacer une boîte de dialogue composant par du code qui afficherait la boîte de dialogue sans utiliser de composant. L'alternative est d'écrire quelques lignes de code pour configurer et afficher une boîte de dialogue chaque fois que vous en avez besoin, et d'ignorer complètement le composant. Ce n'est pas vraiment une optimisation en vitesse ou taille, cependant. Ce n'est pas une optimisation de vitesse puisque votre code ferait exactement ce qu'un composant aurait fait de toute façon, et ce n'est pas une optimisation de taille car l'espace occupé par un composant dans un programme est négligeable.
Les composants de base de données ne sont pas aussi facilement remplaçables que les composants de boîte de dialogue. Près de tout dans Delphi est conçu pour utiliser les descendants des composants de base de données standard. Si vous n'utilisez pas les composants, vous n'utiliserez aucune des fonctionnalités de base de données de Delphi. Vous pouvez utiliser les API natives des bibliothèques de bases de données si vous le souhaitez, mais je pense que ce serait idiot si votre objectif est vraiment l'optimisation et que vous n'avez pas identifié les composants comme la source du comportement non optimal de votre programme. Considérez combien de temps et d'efforts il vous faudrait pour réécrire votre programme sans les composants de base de données.
Les composants de boîte de dialogue sont juste cités en exemple. Si un objet est créé avec la même classe que le composant, toutes les fonctionnalités de Delphi seront disponibles. S'il vous plaît corrigez-moi Si je me trompe en assumant la chose ci-dessus dite. –
Vous avez raison maintenant, mais confus. Vous pensez que le conseil était d'instancier manuellement les composants au lieu de les déposer sur un formulaire ou un module de données. Pour les composants de base de données, cela ne vous donne aucun avantage. En fait, le conseil était de ne pas utiliser les composants * du tout *. Pour les composants de base de données, c'est une très mauvaise idée. –
Merci pour le conseil –
Généralement pas. Il n'y a pas de surcharge supplémentaire dans l'utilisation d'un composant non-visuel. Il est créé très rapidement et fonctionne à l'exécution exactement à la même vitesse qu'un "créé en code".
Si le composant non-visuel est remplacé par du code, alors certains composants non visuels qui ont été utilisés seulement dans une procédure unique seront retirés de la mémoire une fois la procédure terminée. Je parle principalement des composants d'accès aux données. –
Pouvez-vous fournir des références à des blogs ou tout ce qui le recommande? Je n'en ai jamais entendu parler auparavant (ce qui ne veut rien dire, bien sûr :) – Blorgbeard
voir le point no. 8 http://delphi.about.com/od/objectpascalide/a/speedsize.htm –
btw, gexperts est un excellent add-in qui convertit les composants en code. –