Entity Framework VS LINQ to SQL VS ADO.NET avec des procédures stockées ?
Source : Stack Overflow),)
Tout d’abord, si vous démarrez un nouveau projet, optez pour Entity Framework (“EF”) - il génère désormais un SQL bien meilleur (plus similaire à ce que fait Linq to SQL) et est plus facile à maintenir et plus puissant que Linq to SQL (“L2S”). À partir de la sortie de .NET 4.0, je considère Linq to SQL comme une technologie obsolète. Microsoft a été très clair sur le fait qu’il ne poursuivrait pas le développement de L2S.
1) Performance
C’est une question délicate. Pour la plupart des opérations sur une seule entité (CRUD), vous trouverez des performances à peu près équivalentes avec les trois technologies. Vous devez savoir comment EF et Linq to SQL fonctionnent pour les utiliser à leur plein potentiel. Pour les opérations à haut volume comme les requêtes d’interrogation, vous pouvez vouloir qu’EF/L2S “compilent” votre requête d’entité afin que le framework n’ait pas à régénérer constamment le SQL, sinon vous risquez de rencontrer des problèmes de scalabilité. (voir les modifications)
Pour les mises à jour en masse où vous mettez à jour des quantités massives de données, le SQL brut ou une procédure stockée sera toujours plus performant qu’une solution ORM car vous n’avez pas à transférer les données par le réseau vers l’ORM pour effectuer les mises à jour.
2) Rapidité de développement
Dans la plupart des scénarios, EF surpassera largement le SQL brut/les procédures stockées en matière de rapidité de développement. Le concepteur EF peut mettre à jour votre modèle à partir de votre base de données au fur et à mesure de ses changements (sur demande), vous n’avez donc pas de problèmes de synchronisation entre votre code objet et votre code de base de données. Le seul cas où je n’envisagerais pas d’utiliser un ORM est lorsque vous développez une application de type rapport/tableau de bord où vous ne faites aucune mise à jour, ou lorsque vous créez une application uniquement pour effectuer des opérations de maintenance de données brutes sur une base de données.
3) Code propre et maintenable
Sans conteste, EF l’emporte sur SQL/les procédures stockées. Parce que vos relations sont modélisées, les jointures dans votre code sont relativement rares. Les relations entre les entités sont presque évidentes pour le lecteur dans la plupart des requêtes. Rien n’est pire que de devoir passer de couche en couche
(Réponse tronquée)