Je joue avec les fournisseurs de types, en particulier le fournisseur de type Frame-Frame d'entité SQL. J'écris des tests sur une base de données qui a beaucoup d'objets, et il est éloigné afin que la connexion soit un peu lente. Chaque fois que je construis le projet, il faut beaucoup de temps, bon nombre de minutes pour la construction.
Qu'est-ce que je manque pourquoi le compilateur ne cache pas les informations de type?
P.s. C'est encore pire avec F # Interactive ....
3 Réponses :
Essayez d'utiliser l'attribut LOCALALSCHEMAFILE pour le fournisseur de données. Cela pointe vers un fichier .csdl utilisé pour générer les types. Vous pouvez faire mettre à jour le fournisseur de type ce fichier en définissant l'attribut forcerUpdate à true. Pour fonctionner d'un schéma mis en cache, définissez simplement ForcerUpdate sur False. Voici comment je fais cela avec le fournisseur sqldataconnection, qui ressemble beaucoup au fournisseur SQLentTityConnection.
type schema = SqlDataConnection< LocalSchemaFile = "Schema.dbml", ForceUpdate = false, ConnectionString = @"Data Source=<insert your connection string here>" >
Outre ce qui peut être défini comme une «construction lente» (si vous êtes dans le cercle de développement de TDD vert rouge, vous développez rapidement devenus lentement!), j'ai déplacé mon code de fournisseur de type client dans un projet distinct. J'ai déjà eu ForceUpdate définie sur FALSE, mais les constructions toujours ont été lentes (apparemment, une vérification des antécédents de base des fichiers DBML générés se déroulait, dans mes cas Wsdlschema Files réellement).
Après avoir déplacé tout le code de fournisseur de type à un projet distinct, les constructions étaient nettement plus rapides!
Remarque: le chargement de l'interactif était encore plus rapide, vous devez ajouter uniquement la référence à la DLL pour les types
semble que le goulot d'étranglement soit dans la connexion à distance. Je suppose également que vous devez éditer et recmpiler le code d'accès DB fréquemment.
Certains fournisseurs de type peuvent indiquer des scripts SQL locaux au lieu de la connexion en direct, si ce n'est pas le cas, effectuez une DB locale qui reproduit le schéma (et les données statiques des tables «Enum» si vous en avez). La connexion pour les fournisseurs de types / compilateur et pour l'exécution ne doit pas nécessairement être identique.
Il existe des outils pour synchroniser des schémas une fois dans un certain temps SQL SQL SQL (Ceci est génial mais non gratuit), ou simplement régénérer la base de données locale complète de DB et recréer une fois de temps en temps (cela aussi. peut être automatisé mais c'est une histoire différente).
Qu'est-ce que vous comparez contre cela que vous considérez que cela est lent? Quel est votre point de comparaison? Je veux dire, avez-vous essayé les fournisseurs de types contre un dos différent? Votez pour fermer parce que c'est une question trop large.
Une construction qui prend plusieurs minutes à chaque fois prend trop de temps ... je comparais à toutes les autres constructions.
Une construction qui prend plusieurs minutes à chaque fois? J'avais l'habitude de travailler sur une application commerciale C ++ qui a pris 1/2 heure pour construire chaque fois que nous l'avons construite - et c'était après plusieurs tours d'optimisation. Sauf si vous construisez un code de jouet à chaque fois, la compilation va prendre un certain temps. Dire "c'est trop lent" est une sorte d'utilisateur final disant "il est trop difficile à utiliser" - vague et assez inutile.
J'ai un fichier source, et il contient 9 lignes. Le compilateur reconstruit toute la "magie" derrière le fournisseur de type, chaque fois que je compile et cela prend en effet trop de temps.
Bonne question, peut-être que certaines personnes n'ont jamais entendu parler de TDD? Et continuez toujours à nourrir des cartes de frappe sur leur ordinateur ;-) Des constructions rapides et la possibilité de courir des tours de test rapide est très importante!