Veuillez tenir compte de ces hypothèses:
EF et comment l'utiliser correctement de manière optimale. EF dans mes applications en raison de sa compatibilité avec OOP et de sa facilité d'utilisation. Je sais que EF (même avec les meilleures pratiques) présente certains inconvénients en termes de performances par rapport à Dapper ou ADO.NET .
Mais ma question est la suivante: d'après mes hypothèses, ce problème de performances est-il considérable ou je peux utiliser EF en toute sécurité dans mon application Web à fort trafic?
3 Réponses :
Il n'y a rien dans EF qui inhibe l ' évolutivité de votre application. S'il y a une différence de performance, vous pouvez compenser avec des ressources supplémentaires. Et vous pouvez gérer le compromis entre le coût des ressources et le coût de développement au cas par cas, plutôt que de prendre une décision d'architecture à l'avance.
Et une application EF avec des transactions critiques pour les performances sélectionnées implémentées dans ADO.NET et / ou des procédures stockées n'est généralement pas matériellement plus lente ou plus coûteuse à exécuter qu'une application écrite entièrement avec ADO.NET et Procédures stockées.
J'ai une application Web à fort trafic avec des millions d'enregistrements dans des tables de base de données.
Personne (surtout pas la base de données) ne se soucie des millions d'enregistrements sauf si vous oubliez d'y mettre des index. La complexité des requêtes est bien plus intéressante. La plupart des requêtes - en particulier celles qui peuvent utiliser un index au moins pour réduire les nombres analysés - sont une charge insignifiante sur des milliards d'enregistrements, mais une jointure de plus de 15 tables qui force 100 Go de données dans tempdb est un problème.
Je connais suffisamment EF et comment l'utiliser correctement de la manière la plus optimale possible.
J'en doute, en particulier pour EfCore qui semble changer chaque week-end. Mais ok, vous évitez les choses les plus stupides, comme un dbcontext pour toute l'application.
Je sais qu'EF, même avec les meilleures pratiques, présente des inconvénients en termes de performances par rapport à Dapper ou ADO.
Ce n'est absolument pas vrai. Le point est plus - EF fait beaucoup que ni Dapper ni ADO ne font directement, et cela a un prix. C'est comme "Une Ferrari est plus rapide qu'un camion, mais il y a des inconvénients". Le camion est lent - sauf si vous transportez beaucoup de choses. C'est à dire. les requêtes entraînent beaucoup de frais généraux - mais si vous ne vous souciez pas de mettre à jour les données que vous interrogez (généralement dans les applications Web), désactivez le suivi des modifications pour cette requête. Obtenir des objets a une surcharge - ok, ça arrive. Mais vous pouvez filtrer les propriétés que vous matérialisez. Faites-le et la quantité de données diminue. EF n'est pas vraiment super rapide - mais ce n'est pas vraiment horrible non plus. Dapper et ADO (.NET) l'ont battu, mais ils en font moins. En fait, EF est construit sur ADO.NET, car à moins que vous ne prévoyiez d'écrire vous-même toute la pile du réseau, ADO.NET est le seul moyen de communiquer avec la plupart des bases de données.
Tout le problème est le suivant: qu'est-ce que vous pensez être un trafic élevé? J'ai vu EF déployé avec succès dans des applications avec des dizaines de milliers d'utilisateurs parallèles. J'ai ensuite rendu certaines fonctions critiques 100 fois plus rapides parce que les programmeurs professionnels savaient tout sur Ef - mais personne ne leur a appris comment mettre les bons indices sur les tables.
Ef est parfaitement capable sur les grandes applications, mais selon l'utilisation, vous devrez peut-être évoluer vers certains serveurs, à moins que vous n'écriviez un code de niveau utilisateur très efficace et que vous évitiez des choses inefficaces comme l'énumération de toutes les valeurs puis le filtrage en mémoire (et oui, je ont vu cela - en particulier avec les personnes «nous faisons des repositores autour d'Ef» qui pensaient alors que retourner un IEnumerable était une bonne idée).
Tant que vous êtes au courant des meilleures pratiques et que vous vous méfiez des "NE PAS" absolus, oui. Il y aura toujours des développeurs qui ne savent pas ce qu'ils font et qui joint un objet List <> dans une requête Linq, ce qui entraînera la récupération de tous les enregistrements de cette table. Il y en a toujours un autre qui rejoint ou inclut toutes les relations quand ce n'est pas nécessaire. Et un autre qui récupère l'entité avec tous ses champs lorsque le code a réellement besoin d'un champ de cette entité.
Nous utilisons le cœur du framework d'entité dans un grand projet gouvernemental, ayant des centaines de millions de données dans de nombreuses tables et des centaines de requêtes par seconde dans une journée de travail. Tant que vous optimisez également correctement les index de table et les relations, tout va bien. Il ne s'agit pas de la bibliothèque, mais de savoir si vous l'utilisez à bon escient ou non.
Qu'entendez-vous par «respect de la POO»?
@Dai: je veux dire que c'est
ORMdonc vous pouvez l'utiliser plus objectif et ne pas polluer le code avec des commandes SQL nativesRéouverture. Ceci est en partie basé sur une opinion, mais c'est quelque chose sur lequel beaucoup de gens trébuchent et c'est une opinion dans la mesure où "associer un ordinateur est un bon moyen de faire une sauvegarde" - la preuve du bon et du mauvais "benavior" en ce qui concerne EF (core) est empirique et est parfois difficile à gérer.