Je démarre un nouveau développement et je prévois d'utiliser le code d'abord dans le cadre d'entité 4.1.
J'ai déjà utilisé le modèle en premier et j'ai trouvé quelques problèmes de performance autour du contexte de chargement, premiers appels aux SAVECHANGES () et dans la procédure de fixation de l'association.
Quelqu'un a comparé la performance de ces deux techniques - ou, à la fin de la journée, sont-ils insignifiants?
Merci.
3 Réponses :
Je crois qu'il n'y a pas de différence dans la performance. Code - premier, Model-Premier, la base de données - d'abord sont des stratégies de modélisation à Heure de conception . Pour les classes de modèle et de base de la base de données - Premières entités et un Gardez également à l'esprit que le bénéfice que le modèle qui vous donne d'abord est plutôt limité à mon avis: vous avez simplement la possibilité de créer vos classes de modèle sur une surface de conception dans VS2010. Mais il y a plus d'inconvénients de l'autre côté: le modèle par défaut T4 n'est pas très fin granulaire dans la création du code du modèle. Par exemple: il ne met pas les attributs En d'autres termes. Il est très probable que vous ayez à modifier le code généré (ajout d'attributs, en supprimant les propriétés de navigation indirigé, en ajoutant le code de cartographie fluide, etc.) afin d'obtenir les classes de modèle finis que vous souhaitez utiliser. Dès que vous l'avez fait, il devient difficile de faire des modifications dans le concepteur de modèle car le générateur DBContext écrasera toutes vos modifications apportées à la main dans le code. à mon avis d'opinion - d'abord avec EF 4.1 n'est utile que si vous avez déjà un modèle conçu dans la surface designer par exemple à partir d'un projet EF 4.0 plus ancien et que vous souhaitez migrer votre projet vers EF 4.1 Dans ce cas, le générateur DBContext pourrait être utile pour créer initial code pour vous. À partir de là, je procéderais à travailler seul dans le code qui signifie: travailler avec le code - premier. Si vous commencez par un nouveau projet, je préférerais le code - d'abord du début. Même si vous voulez vraiment ou avez besoin de cette représentation visuelle du modèle de la surface designer également dans le code, vous pouvez tout simplement créer un fichier EDMX à partir de votre dbcontext et l'ouvrir dans VS2010 pour afficher vos classes de modèle et leurs relations dans le concepteur: < / p> Il existe en fait un point où EF 4.1 recogme la différence si un modèle provient du modèle d'abord (c'est-à-dire Un fichier de modèle EDMX et une surface de concepteur) ou s'il s'agit d'un modèle de code pur-premier - et c'est la chaîne de connexion. Si vous créez un modèle à partir du modèle - Vous obtenez une chaîne de connexion qui contient des références aux fichiers de métadonnées de modèle, comme: tandis que pour le code, tout simplement un "normal "String de connexion sans références de métadonnées est utilisée: Vous pouvez également utiliser la deuxième chaîne de connexion simple sans problèmes également pour un modèle créé via le modèle-premier. Mais l'extrait de code ci-dessus (créant un EDMX à partir de dbcontext) jette une exception avec la première chaîne de connexion indiquant que Comment interpréter cela? Cela signifie-t-il que cela utilise réellement les données du fichier EDMX spécifié dans la chaîne de connexion lorsque le modèle est construit en mémoire? Dans ce cas, il pourrait être théoriquement une différence de performance entre le code - premier et le modèle - d'abord (au moins au modèle de modèle de modèle). Mais je ne pense pas que les métadonnées soient en réalité traitées. Mais l'exception mentionnée est quelque peu bizarre. Pourquoi EF 4.1 m'empêche-t-il de créer un fichier de modèle EDMX lorsque mon modèle provient du modèle en premier? Peut-être juste pour éviter une confusion et un gâchis possibles avec deux fichiers EDMX? Je ne sais pas. dBContext sera créée avec un modèle T4. À maxlength sur les propriétés, il crée toujours des propriétés de navigation des deux côtés sur une relation (vous ne voulez souvent pas et avez besoin des deux côtés) et le transitaire OnModelCreatting Méthode dans DBContext Il suffit de contenir la ligne unique lancer une nouvelle intention non intentionnelleCodeFirstException (); qui n'est pas particulièrement impressionnant. Vous pouvez modifier le modèle et la partie CSDL du fichier EDMX cependant pour obtenir plus de granularité lorsque les classes de modèle et le dbcontext sont générés (grâce à Ladislav pour son commentaire ci-dessous sur cette option). welledmx ne peut être utilisé qu'avec le code - premier mais pas modèle - Premier ou base de données - Premier. Donc, évidemment, le dBContext traite ou stocke en quelque sorte les informations de métadonnées à partir de la chaîne de connexion.
+1, mais je pense que vous manquez un peu de magie que le code - premiers Pocos passe au moment de l'exécution. Par rapport aux retards de réseautage réels, cette magie est évidemment bon marché, mais le modèle doit également être vérifié contre une somme de contrôle stockée par la base de données, qui entraîne évidemment des coûts de traitement et de mise en réseau supplémentaires. Mais, comme la plupart des gens, je peux vivre avec cela, car cela sauve l'heure du développeur. Mais puisque CF vous encourage à utiliser ces Pocos, vous pouvez être bloqué lorsque vous souhaitez mettre à jour vos définitions de table ultérieurement (ex. Produit expédié, ajouter une table, modifier la somme de contrôle).
@Gleno: Le modèle n'est validé qu'une fois lorsque le contexte est utilisé pour la première fois après le démarrage de l'application. De plus, cette fonctionnalité peut être désactivée.
@Slauma: Même avec le modèle Tout d'abord, vous pouvez obtenir une granularité souhaitée et vous pouvez ajouter des annotations de données souhaitées, mais cela nécessite des modifications dans le modèle T4 et la plupart du temps, des modifications manuelles de la partie CSDL de XML (annotations structurelles).
@Ladislav: Je vois, je n'avais pas de modification du modèle et d'Edmx à l'esprit. J'ai ajouté une note à ce sujet dans ma réponse.
@Sluama @gleno @Ladislav remercie tout pour des commentaires très utiles. Je n'étais pas au courant de l'EdmxWriter, donc c'est intéressant. J'aimerais utiliser des modèles T4 simplement pour augmenter la productivité afin que le fichier EDMX est important.
Mon expérience dans un environnement de transaction élevé a été une certaine dégradation des performances après la conversion en premier au code. Ce n'était pas grave mais peut-être autour de 2% mais toujours que sux et enquête sur la manière de récupérer la performance.
Oui, il existe des différences de performance entre le modèle premier (EF 4.0) et le code d'abord (EF 4.1 - 4.3.1):
Vous ne pouvez pas Pré-générer des vues de requête internes . Cela signifie que chaque fois que EF tente d'exécuter sa première requête (par domaine App), il devra effectuer une opération coûteuse pour générer ces points de vue, en fonction de votre complexité du modèle. Cela affecte généralement les performances de démarrage des applications et peut faire le débogage assez gênant.
Vous ne pouvez pas utiliser requêtes compilées . Cela peut affecter sérieusement les requêtes utilisées souvent, surtout complexes. Cela peut devenir un goulot d'étranglement grave et un CPU HOG. Seule EF 5.0 (qui sera incluse avec .NET 4.5) corrige ce problème en compilant automatiquement toutes les requêtes, y compris Code Premières requêtes.
Dans mon code d'expérience, il est d'abord plus lent que le modèle - premier (ou plutôt la base de données - d'abord). Mais cela n'a pas d'importance, car vous pouvez changer de fournisseur d'ormes plus tard. Ce qui me bugs avec une approche des FC, c'est que si votre base de données est suffisamment complexe, vous voulez que vous souhaitiez la mettre à jour, et il n'y a pas de mécanisme pour augmenter les bases de données - même si vous ajoutez des colonnes complètement non pertinentes.
Merci Gleno. Je soupçonne que toute différence de performance est négligeable - je voulais juste entendre une expérience pratique. En général (MF et CF), EF est médiocre lors de la manipulation des mises à jour de schéma (chute et recréement de la DB est à peine élégante) bien qu'il existe des moyens d'extraire les changements. J'évite certainement le code de réparation où je peux - cela peut être un cauchemar.
Le modèle n'est-il pas d'abord juste une stratégie temps de conception ? À la fin, vous créez des classes de modèle et un dBContext à partir d'un modèle T4. À Runtime Peu importe si vous avez écrit à la main ces classes (code-premier) ou si elles ont été autogogenerées à partir d'un outil de conception (modèle en premier).
@Slauma: C'est la bonne réponse;)
@Slauma @ladislav. Merci je n'étais pas sûr. J'ai trouvé un article msdn.microsoft.com/en-us/magazine/hh148150. ASPX où il stipule "quelle que soit la technique de modélisation que vous choisissez-la base de données d'abord, modèle premier ou code d'abord, une fois que vous avez créé un modèle, vous ne remarquerez aucune différence lorsque vous commencez à interroger, interagir avec et persistent des entités Utilisation du délai d'exécution de l'entité Framework au moyen des classes du modèle ". C'est donc assez clair alors. Merci les gars.
J'ai converti mon commentaire en réponse et j'ai étendu un peu.
@Slauma, @ladislav - Si vous finissez par utiliser les pocos de conception, n'est-ce pas une performance d'exécution touchée à cause de toute la magie de réflexion de la propriété virtuelle? Oh, sans parler des vérifications de vérification des modèles supplémentaires que je ne peux supposer que des incendies chaque fois que vous introduisez un nouveau dBContext, qui est censé être bon marché. Comme je l'ai déjà dit, vous pouvez bien sûr changer le fournisseur ORM à ce que vous voulez, après avoir créé votre modèle. Mais ce n'est pas la philosophie de la première approche du code comme je le vois. Couplé avec le fait que CF ne convient pas à une augmentation de la base de données, je me sens besoin d'avertir avec un grand type.