1. Choix de SqlDataRead et Dataset Avantages de Sqldataread : La lecture des données est très rapide. Si les données renvoyées ne nécessitent pas beaucoup de traitement, il est recommandé d'utiliser SqlDataReader, dont les performances sont bien meilleures que celles de datset. Inconvénients : La connexion à la base de données ne peut pas être fermée tant que les données n'ont pas été lues
(SqlDataReader lit les données dans le sens d'une avance rapide. La classe SqlDataReader fournit un moyen de lire le flux de données en avant uniquement extrait de la base de données SQL Server. Elle utilise le flux de données de SQL Server. Le format de transmission de données réseau natif lit les données directement à partir de la connexion à la base de données. DataReader doit être explicitement fermé à temps pour libérer la connexion de données à temps.)
L'ensemble de données lit les données et les met en cache en mémoire. Inconvénients : utilisation élevée de la mémoire. Si vous devez effectuer beaucoup de traitements sur les données renvoyées, il est préférable d'utiliser Dataset pour réduire les opérations de connexion à la base de données. Avantages : Vous n'avez besoin de vous connecter qu'une seule fois pour fermer la connexion à la base de données
. En général, si vous souhaitez lire une grande quantité de données et ne pas effectuer beaucoup de traitements sur les données renvoyées, utilisez SqlDataReader pour une grande quantité. traitement sur les données renvoyées, il est plus approprié d'utiliser datset Le choix de SqlDataReader et Dataset dépend de la réalisation des fonctions du programme.
2. ExecuteNonQuery et ExecuteScalar
n'ont pas besoin de renvoyer un ensemble de résultats lors de la mise à jour des données. Il est recommandé d'utiliser ExecuteNonQuery. Puisqu’aucun jeu de résultats n’est renvoyé, la transmission des données réseau peut être omise. Il renvoie simplement le nombre de lignes affectées. Si vous avez uniquement besoin de mettre à jour les données, la surcharge de performances d'ExecuteNonQuery est relativement faible.
ExecuteScalar renvoie uniquement la première colonne de la première ligne du jeu de résultats. Utilisez la méthode ExecuteScalar pour récupérer une valeur unique (telle qu'un numéro d'identification) de la base de données. Cette opération nécessite moins de code que l'utilisation de la méthode ExecuteReader pour effectuer les opérations requises pour générer une valeur unique sur les données renvoyées.
*Mettez simplement à jour les données à l'aide de ExecuteNonQuery. La requête d'une valeur unique utilise l'option de liaison de données ExecuteScalar
3. Liaison de données
Méthode de liaison générale DataBinder <%# DataBinder.Eval(Container.DataItem, "field name") %> use DataBinder.eval La liaison ne se soucie pas de la source de données (Dataread ou ensemble de données). Vous n'avez pas à vous soucier du type de données. eval convertira cet objet de données en chaîne. Beaucoup de travail a été effectué sur la liaison sous-jacente, en utilisant les capacités de réflexion. Ce n’est pas parce qu’il est pratique à utiliser que cela affecte les performances des données. Jetons un coup d'œil à <%# DataBinder.Eval(Container.DataItem, "field name") %>. Lorsqu'il est lié à un ensemble de données, DataItem est en fait un DataRowView (s'il est lié à un lecteur de données (dataread), il s'agit d'un IdataRecord.) Par conséquent, le convertir directement en DataRowView améliorera considérablement les performances.
<%# ctype(Container.DataItem,DataRowView).Row("field name") %>
*Il est recommandé d'utiliser <%# ctype(Container.DataItem,DataRowView).Row("field name") %> pour les données obligatoire. . Lorsque la quantité de données est importante, la vitesse peut être augmentée des centaines de fois. Faites attention à deux aspects lors de son utilisation : 1. Vous devez ajouter <%@ Import namespace="System.Data"%> à la page 2. Faites attention à la casse du nom du champ (faites particulièrement attention). S'il n'est pas cohérent avec la requête, dans certains cas, il sera plus lent que <%# DataBinder.Eval(Container.DataItem, "field name") %>. Si vous souhaitez améliorer encore la vitesse, vous pouvez utiliser la méthode <%# ctype(Container.DataItem,DataRowView).Row(0) %>. Cependant, sa lisibilité n'est pas élevée.
Ce qui précède est la méthode d'écriture de vb.net. En c# : <@% ((DataRowView)Container.DataItem)["field name"] %>
Le moyen le plus simple de visualiser l'état de chaque processus d'exécution sur la page : vous pouvez visualiser les détails si l'attribut trace de la page est vrai.
1. Utilisez des procédures stockées :
1. Performances : les procédures stockées offrent de nombreuses fonctionnalités avancées que l'on ne trouve pas dans le langage SQL standard. Sa capacité à transmettre des paramètres et à exécuter des expressions logiques aide les concepteurs d'applications à gérer des tâches complexes. De plus, la procédure stockée est stockée sur le serveur local, ce qui réduit la bande passante de transmission réseau et le temps d'exécution requis pour exécuter la procédure. (La procédure stockée a précompilé l'instruction sql, sa vitesse d'exécution est donc beaucoup plus rapide que l'exécution de l'instruction sql dans le programme)
2. Structure du programme : du point de vue de l'évolutivité du programme, l'utilisation de procédures stockées affectera les modifications futures du programme. pour plus de commodité. Par exemple, si la structure de la base de données change, il suffit de modifier la structure de stockage correspondante et la partie appelante du programme. Cette partie n'entre pas dans le cadre de cet article et appartient à la conception de la structure du programme. Je ne m’étendrai donc pas ici.
3. Sécurité du programme : les attaques par injection SQL peuvent être évitées en utilisant des procédures stockées.
2. Optimisation des instructions de requête (pour SQL Server2000)
De nombreuses personnes écrivent des instructions SQL uniquement dans ce but, sans tenir compte de l'efficacité d'exécution de l'instruction SQL. Ici, je propose uniquement une méthode pour optimiser l'ordre des tables. (L'optimisation et les principes des instructions SQL seront abordés dans mes notes d'étude SQL Server2000.)
Pour l'efficacité de l'exécution des instructions SQL, vous pouvez utiliser l'analyseur de requêtes de SQL Server2000 pour visualiser le processus d'exécution des déclarations.
Optimiser l'ordre des tables : dans des circonstances normales, sqlserver optimisera automatiquement les connexions aux tables. Par exemple : sélectionnez name,no depuis A, rejoignez B sur A. id=B.id, rejoignez C sur C.id=A.id où name='wang'Bien que
la table A soit répertoriée en premier dans From, puis B et enfin C'est C. Mais le serveur SQL peut d'abord utiliser la table c. Son principe de sélection est de limiter la requête à une seule ligne ou à quelques lignes, afin de réduire la quantité totale de données recherchées dans d'autres tables. Dans la plupart des cas, SQL Server fera le choix optimal, mais si vous constatez qu'une requête de jointure complexe est plus lente que prévu, vous pouvez utiliser l'instruction SET FORCEPLAN pour forcer SQL Server à utiliser les tables dans l'ordre dans lequel elles apparaissent. Comme dans l'exemple ci-dessus, ajoutez : SET FORCEPLAN ON.......SET FORCEPLAN OFF L'ordre d'exécution de la table sera exécuté dans l'ordre que vous avez écrit. Affichez les 2 efficacités d'exécution dans Query Analyzer pour choisir l'ordre dans lequel les tables sont jointes.
*Utilisez SET FORCEPLAN pour sélectionner la séquence de connexion à la table
3. L'optimisation de la page (.aspx)
se concentre principalement sur plusieurs attributs de page
1. EnableViewState (l'état d'affichage de la page). Définissez sur false s’il n’y a pas d’exigences particulières. Avec ViewState, chaque objet doit d'abord être sérialisé dans ViewState, puis désérialisé via la publication, l'utilisation de ViewState est donc gratuite. Utilisez le moins d'objets possible et, si possible, réduisez le nombre d'objets que vous placez dans ViewState. Viewstate peut essentiellement être désactivé dans les situations suivantes :
(1) Contrôle de page (.ascx)
(2) La page n'est pas renvoyée à elle-même.
(3) Aucun traitement événementiel pour les contrôles n’est requis.
(4) Le contrôle n'a pas de valeurs de propriété dynamiques ou liées aux données (ou est géré dans le code pour chaque postpack)
Désactivez ViewState pour une seule page ou pour chaque page, comme suit : Page unique : <%@ Page EnableViewState=" False" %> Chaque page : Dans web.config
2. Mise en page. Modèle de mise en page. Il est recommandé d'utiliser Flowlayout (les éléments sont ajoutés sans attributs de positionnement absolus). Gridlayout (attributs de positionnement absolus) produira plus de code que Flowlayout en raison de l'utilisation du positionnement absolu, principalement les informations de positionnement du contrôle.
3. Lors de la libération du projet, n'oubliez pas de libérer l'état Debug de la page.
4. Optimisation du langage HTML. Ma suggestion est de maîtriser Html/JavaScript et d'utiliser moins de code généré automatiquement par vs.net2003. Cela générera automatiquement du code HTML inutile.
5. Définir la navigation intelligente sur true peut améliorer considérablement les performances des utilisateurs. L'activation de cette propriété a peu d'impact sur le client et le serveur. Elle permet de mettre à jour intelligemment les parties qui doivent être mises à jour.
4. Sélection des contrôles :
Choix de contrôles HTML et de contrôles serveur. La commodité et la réalisation fonctionnelle apportées par les contrôles serveur sont inégalées par les contrôles HTML. Mais cela s’obtient au détriment des ressources côté serveur. Ma suggestion personnelle : si le contrôle HTML ne peut pas réaliser les fonctions qu'il souhaite réaliser, et qu'il ne peut pas être réalisé lorsqu'il est combiné avec certains langages de script (tels que javascrpt/vbscript). Ce n'est qu'alors que le contrôle du serveur sera sélectionné. Après avoir sélectionné le contrôle serveur, essayez d'optimiser son contrôle, comme en annulant certains états de page, etc. (voir spécifiquement l'optimisation du contrôle
Sélection des contrôles serveur : Expliquez principalement plusieurs contrôles de données courants :
DataGrid : est livré avec le plus puissant
).affichage des données Le contrôle intègre de nombreuses fonctions pratiques telles que la modification, la suppression, l'ajout et la pagination de données. Si vous avez uniquement besoin d'afficher des données, essayez de ne pas choisir DataGrid (il stocke toutes les données dans viewstate). N'utilisez pas non plus la fonction de pagination intégrée. Microsoft a fait beaucoup de travail sur la couche inférieure de pagination automatique. est pratique à utiliser, la surcharge de performances est énorme.
DataList : il a beaucoup moins de fonctions que DataGrid. Mais c’est beaucoup plus personnalisable. L'affichage unique des données multilignes nous apporte beaucoup de commodité. Il peut essentiellement implémenter les fonctions que DataGrid peut réaliser. Il est donc recommandé de l'utiliser.
Répéteur : Le moins fonctionnel, mais très personnalisable. Il est recommandé de l'utiliser si vous avez uniquement besoin d'afficher des données. En raison de la réduction de nombreuses fonctions, la consommation des performances du serveur est minime. Par conséquent, s'il s'agit d'afficher des données, je choisis essentiellement Repeater, puis DataList et enfin DataGrid
* essayez de choisir le contrôle html. Les fonctions implémentables sur le client sont implémentées sur le client (maîtrisant javascript), réduisant ainsi la pression sur le serveur. Séquence de sélection du contrôle des données : Repeater, DataList, DataGrid
5. Optimisation des contrôles serveur :
1.
L'état d'affichage du contrôle Viewstate est fondamentalement le même que l'état d'affichage de la page. Utilisé pour sauvegarder certains états du contrôle. Le principe de traitement est le même que celui du traitement de l'état d'affichage de la page. Si vous êtes intéressé, vous pouvez utiliser Datagrid pour lier des données afin de tester la quantité de données enregistrées par viewstate. Les données enregistrées sont fondamentalement les mêmes que la quantité de données affichées par Datagrid.
2. Ispostpack
est par défaut false. Il doit être défini sur true lorsqu'un événement doit être généré.
L'optimisation du contrôle dépend principalement de votre familiarité avec ce contrôle. Mieux vous comprenez le fonctionnement interne d’un contrôle, mieux vous pourrez l’optimiser de manière appropriée.
L'optimisation des performances ne peut pas être expliquée en quelques phrases. Ce que j'ai écrit n'est que la pointe de l'iceberg. L'optimisation des performances repose sur l'accumulation d'expérience quotidienne et la compréhension continue des principes de fonctionnement du programme.
6. Problèmes d'exception
Il n'est pas nécessaire d'utiliser des exceptions pour des problèmes généraux, tels que des problèmes où l'utilisateur n'existe pas dans le forum, le mot de passe de l'utilisateur est incorrect, etc., car l'instanciation d'une exception nécessite beaucoup de ressources et nécessite de remplir les informations sur l'exception (type d'exception, emplacement de l'exception où l'exception est levée) etc.), bien sûr, il ne s'agit pas d'éviter d'utiliser les exceptions, mais de gérer les exceptions nécessaires. Le principe des exceptions est le suivant : ne les utilisez pas si vous le pouvez, et ne générez pas vos propres exceptions si vous pouvez utiliser les exceptions existantes dans le système.