Obtenez les meilleures performances de Entity Framework 6 comme Dapper.NET

c# crud dapper entity-framework performance

Question

J'ai utilisé dapper.net comme micro-orm, la vitesse et la performance sont fantastiques!

Les opérations CRUD simples dans Dapper sont plus rapides qu'Entity Framework 6.

Speed-Comparison-Dapper-vs-Entity-Framework

Mais si je veux la rapidité et la performance d’Entity Framework 6 comme Dapper , que dois-je faire?

Je n’ai pas besoin de toutes les fonctionnalités avancées d’Entity Framework 6,

Puis-je désactiver certaines fonctionnalités pour augmenter la vitesse et les performances d'Entity Framework 6? Laquelle ?

Quelles fonctionnalités sont coûteuses et augmentent la vitesse pour les désactiver? (Veuillez préciser)

Réponse acceptée

Commencez par profiler les commandes SQL réellement émises par Entity Framework. Selon votre configuration (POCO, entités à suivi automatique), les optimisations sont nombreuses. Vous pouvez déboguer les commandes SQL (qui ne devraient pas différer entre le mode débogage et le mode de publication) à l'aide de la méthode ObjectSet<T>.ToTraceString() . Si vous rencontrez une requête qui nécessite une optimisation supplémentaire, vous pouvez utiliser certaines projections pour donner à EF plus d'informations sur ce que vous essayez d'accomplir.

Exemple:

Product product = db.Products.SingleOrDefault(p => p.Id == 10);
// executes SELECT * FROM Products WHERE Id = 10

ProductDto dto = new ProductDto();
foreach (Category category in product.Categories)
// executes SELECT * FROM Categories WHERE ProductId = 10
{
    dto.Categories.Add(new CategoryDto { Name = category.Name });
}

Peut être remplacé par:

var query = from p in db.Products
            where p.Id == 10
            select new
            {
                p.Name,
                Categories = from c in p.Categories select c.Name
            };
ProductDto dto = new ProductDto();
foreach (var categoryName in query.Single().Categories)
// Executes SELECT p.Id, c.Name FROM Products as p, Categories as c WHERE p.Id = 10 AND p.Id = c.ProductId
{
    dto.Categories.Add(new CategoryDto { Name = categoryName });
}

Je viens de taper cela dans ma tête, donc ce n'est pas exactement comment cela serait exécuté, mais EF fait de bonnes optimisations si vous lui indiquez tout ce que vous savez de la requête (dans ce cas, nous aurons besoin de la catégorie- des noms). Mais cela ne ressemble pas à un chargement rapide (db.Products.Include ("Catégories")) car les projections peuvent réduire davantage la quantité de données à charger.


Réponse populaire

Le fait est que des produits tels que Entity Framework seront TOUJOURS lents et inefficaces, car ils exécutent beaucoup plus de code.

Je trouve également ridicule que des personnes suggèrent d'optimiser les requêtes LINQ, d'examiner le code généré par SQL, d'utiliser des débogueurs, de pré-compiler, de prendre beaucoup de mesures supplémentaires, etc. Personne ne dit - Simplifiez! Tout le monde veut encore compliquer les choses en faisant encore plus de pas (perdre du temps).

Une approche sensée serait de ne pas utiliser EF ou LINQ du tout. Utilisez du SQL simple. Il n'y a rien de mal à cela. Ce n’est pas parce qu’il existe une mentalité de groupe parmi les programmeurs et qu’ils ressentent le besoin urgent d’utiliser chaque nouveau produit, cela ne veut pas dire que c’est bon ou que cela fonctionnera. La plupart des programmeurs pensent que, s'ils intègrent chaque nouvelle pièce de code publiée par une grande entreprise, cela en fait un programmeur plus intelligent. pas vrai du tout. La programmation intelligente consiste principalement à faire plus avec moins de maux de tête, d’incertitudes et en un minimum de temps. Souvenez-vous du temps! C’est l’élément le plus important. Essayez donc de trouver le moyen de ne pas le gaspiller pour la résolution de problèmes dans un code mauvais / gonflé écrit simplement pour vous conformer à de étranges «motifs» étranges.

Détendez-vous, profitez de la vie, faites une pause dans le codage et arrêtez d'utiliser des fonctionnalités supplémentaires, du code, des produits, des "modèles". La vie est courte et la vie de votre code est encore plus courte, et ce n'est certainement pas sorcier. Supprimez les couches telles que LINQ, EF et autres, et votre code fonctionnera efficacement, s’échelonnera et, oui, il sera toujours facile à gérer. Trop d'abstraction est un mauvais "motif".

Et c'est la solution à votre problème.



Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi