Lors de l'utilisation de TableAdapters générés automatiquement, quelle est la méthode suggérée pour gérer l'instanciation répétée?

J'utilise les trucs de jeu de données .xsd (que je déteste) pour générer automatiquement des classes TableAdapter pour du code backend. Je ne les avais pas vraiment utilisées auparavant, ayant tendance à privilégier les commandes manuelles et les process stockés autant que possible (pour différentes raisons liées à la vitesse: ces xsds jouent avec des tables dynamiques et de très grandes quantités de colonnes) Le grand nombre de mes méthodes, donc ma question est la suivante:Lors de l'utilisation de TableAdapters générés automatiquement, quelle est la méthode suggérée pour gérer l'instanciation répétée?

Est-ce que le code généré automatiquement se rationaliser lui-même afin qu'une classe d'adaptateur complète ne soit pas créée sur une instance, et partage plutôt certaines données statiques (telles que les informations de connexion), et sinon serait-il mieux pour moi d'avoir une sorte de fournisseur de classe singleton/statique qui peut me donner accès à leurs méthodes si nécessaire sans la surcharge de créer un nouvel adaptateur chaque fois que je veux obtenir des informations?

Cheers, Ed

Source

2010-01-26 Ed James

Y at-il vraiment beaucoup de frais généraux pour l'instanciation d'un TA? La seule chose que je vois dans son constructeur est 'this.ClearBeforeFill = true;' et ses propriétés CommandCollection et Connection ne sont définies qu'une seule fois pendant la durée de vie de l'AT ..... ce qui signifie que les frais généraux de configuration ne se produisent que lorsque vous faites votre premier appel à l'une de ses méthodes publiques ..... la méthode Fill, par exemple. Donc, tant que cela reste dans la portée, je ne m'attendrais pas à des problèmes de performance. Suis-je loin de la base ici? – Ken

C'est assez proche de la réponse que je suis après pour être honnête, je cherche à savoir si, comme vous le dites, il n'y a pas de coup de performance pour en créer un nouveau chaque fois que je veux exécuter une commande (pas tout à fait littéralement, mais très proche: le code qui les utilise est plutôt spagetti en raison des complexités du système), ou si je devrais créer un modèle de fournisseur mis en cache pour les servir quand j'en ai besoin. –

Peut-être utiliser DotTrace pour vérifier ma réclamation. (BTW ... j'utilise VS2005) Une chose que je fais généralement, car il y a une chaîne de connexion au moment de la conception, est de faire un constructeur de surcharge dans une classe partielle pour l'adaptateur de table qui accepte et définit la chaîne de connexion de production, pas la chaîne de temps de conception. Ceci, cependant, a un certain coût, car il établit la connexion à l'instanciation. – Ken

Si vous êtes préoccupé par les performances, vous pouvez toujours exécuter un test de performances pour voir les performances, le cas échéant.

Désolé, vous n'avez pas trouvé de réponse utile. Ce que je voulais dire, c'est que même si vous avez reçu des réponses, elles semblaient toutes subjectives et ne reposaient pas sur des données concrètes. Donc, si vous aviez des raisons d'être préoccupé par le fait qu'il y avait un problème de performance dans votre application, vous devriez le mesurer.

Il n'y a aucune raison de refactoriser une zone pour la performance à moins qu'il y ait un problème réel.

Source

2010-02-09 08:40:32

Je pourrais: ou je pourrais demander sur stackoverflow et économiser moi-même un peu de temps, et voir s'il y a une forme de consensus de groupe. . Oh, attends une seconde ... –

je tends en fait à instancier un très faible nombre d'adaptateurs (habituellement seulement un de chaque type). Je n'ai jamais essayé de les utiliser comme sur les variables de la pile (instanciées au besoin), donc je n'ai jamais rencontré votre question, mais je comprends votre inquiétude. D'après ce que je sais les aqdapters eux-mêmes peuvent être assez lourds dans l'instanciation, mais le vrai tueur est la connexion. Ce que je fais est je marque le modificateur comme Public de connexion de l'adaptateur dans le concepteur .xsd je peux attribuer la propriété tout ce que je besoin d'utiliser et de maintenir une poignée serrée sur l'ouverture et la fermeture des connexions:

void Load() { 
    using (SqlConnection conn = ...) { 
    conn.Open(); 
    invoicesAdapter.Connection = conn; 
    customersAdapter.Connection = conn; 
    invoicesAdapter.Fill(dataSet.Invoices); 
    customersAdapter.Fill(dataSet.Customers); 
    } 
} 

void Save() { 
    using (SqlConnection conn = ...) { 
    conn.Open(); 
    invoicesAdapter.Connection = conn; 
    customersAdapter.Connection = conn; 
    invoicesAdapter.Update(dataSet); 
    customersAdapater.Update(dataSet); 
    } 
}

J'ai omis le contrôle des transactions et le traitement des erreurs pour plus de concision.

Source

2010-02-09 01:07:06

Lors de l'utilisation de TableAdapters générés automatiquement, quelle est la méthode suggérée pour gérer l'instanciation répétée?

Répondre

Questions connexes