Discussion :

[M_Makia]

Bonjour à toutes et tous.
Dans mes discussions que je peux avoir avec mes collègues, connaissances ou autres professionnels que je croise, il n'est pas rare qu'on me dise que Entity Framework n'est pas fait pour être mis en production et qu'il est plus fait pour faire du prototypage.
De manière générale on me dit que Entity framework c'est pour faire du Quick and dirty.

Je suis conscients qu'il y a des avantages et des inconvénients a utilisé cet ORM , mais sans parler de ces points je souhaiterais savoir si vous pensez que de manière générale Entity Framework doit être seulement utilisé pour faire des applications en mode quick and dirty et qu'une "bonne" appli ne doit pas utiliser d'ORM pour sa couche d’accès aux données ?

Merci.

[GuruuMeditation]

je ne suis pas spécialiste EF, mais EF peut être mis en prod (je l'a déjà fait)

Mais si c'est une app très gourmande question DB et qui doit être très rapide et optimisée, avec un volume conséquent, je regarderais probablement à autre chose, car c'est plus lent qu'en direct.

[dfiad77pro]

J'ai un exemple d'une appli ( pas lente ) que j'ai conçus pour une grosse entreprise qui est en prod maintenant

- Base oracle 11g
- EF5 /.NET 4.5
- 95 tables dédiés: dont une de 35 millions de lignes
- 1500 tables externes en lecture
- 550 utilisateurs réels

Elements complexes de l'appli :
- un utilisateur peut insérer jusqu'a 30 000 lignes ( tarifs)
- utilisation d'un cache de lecture pour les éléments non temps réel ( récupération de milliers de lignes)
- de nombreux calculs statistiques


Et ça fonctionne très bien si on sait se servir d'entity framework :

- Utilisation d'un contexte par fenêtre
- Configuration suivante du context
Configuration.AutoDetectChangesEnabled = false;
Configuration.ValidateOnSaveEnabled = false;
Configuration.LazyLoadingEnabled = false;
Configuration.ProxyCreationEnabled = false;
- Utilisation de procédure stockés ou requête bindées pour les écritures de plus de 15 lignes
- Eviter les refresh sur binding pour récupérer une séquence après l'insertion d'une ligne
- Utilisation du Notracking et de dictionnaire pour les données en lecture
- faire attention au jointures LINQ de complexité supérieure à 3 (surtout dans ce qui est généré via include)
- faire attention au références des objets récupérés afin de pouvoir vider la mémoire facilement
- Utiliser les vue prés-générés
...


En gros EF est un plus indéniable pour coder une application, mais il faut passer beaucoup de temps au début sur l'architecture applicative ( ou du service).