Entity Framework VS LINQ to SQL VS ADO.NET avec des procédures stockées?
Comment évalueriez-vous chacun d'eux en termes de:
- Performance
- Vitesse de développement
- Code soigné, intuitif et maintenable
- La flexibilité
- Global
J'aime mon code SQL et je suis donc toujours un fan inconditionnel d'ADO.NET et des procédures stockées, mais j'ai récemment joué à Linq en SQL et j'ai été époustouflé par la rapidité avec laquelle j'ai écrit ma couche DataAccess et j'ai décidé de dépenser de l'argent. un peu de temps vraiment comprendre soit Linq to SQL ou EF ... ou ni?
Je veux juste vérifier qu’il n’existe dans aucune de ces technologies une faille qui rendrait mon temps de recherche inutile. Par exemple. les performances sont terribles, c'est cool pour les applications simples mais cela ne peut que vous mener jusque-là.
Mise à jour: Pouvez-vous vous concentrer sur les SP EF VS L2S VS plutôt que sur les SP ORM VS. Je suis principalement intéressé par EF VS L2S. Mais je tiens également à ce qu’ils soient comparés à des processus stockés, car je connais bien SQl.
Tout d’abord, si vous démarrez un nouveau projet, utilisez Entity Framework ("EF") - il génère maintenant un SQL bien meilleur (plus semblable à Linq to SQL) et est plus facile à maintenir et plus puissant que Linq to SQL (" L2S "). Depuis la publication de .NET 4.0, Linq to SQL est une technologie obsolète. MS a été très ouvert sur le fait de ne pas poursuivre le développement de L2S.
1) Performance
C'est difficile à répondre. Pour la plupart des opérations à entité unique ( CRUD ), vous obtiendrez des performances à peu près équivalentes avec les trois technologies. Vous devez savoir comment EF et Linq to SQL fonctionnent afin de les utiliser au maximum. Pour les opérations à volume élevé telles que les requêtes d'interrogation, vous souhaiterez peut-être que EF/L2S "compile" votre requête d'entité, de sorte que le framework ne nécessite pas de régénérer constamment le code SQL, ou vous pouvez vous heurter à des problèmes d'évolutivité. (voir modifications)
Pour les mises à jour en masse où vous mettez à jour des quantités massives de données, un SQL brut ou une procédure stockée fonctionnera toujours mieux qu'une solution ORM car vous n'avez pas besoin de marshaller les données sur le réseau pour les mettre à jour.
2) Vitesse de développement
Dans la plupart des scénarios, EF supprimera les processus SQL/stockés nus lorsqu'il s'agira de la vitesse 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 modifications (sur demande). Ainsi, vous ne rencontrez pas de problèmes de synchronisation entre votre code d'objet et votre code de base de données. La seule fois où je n’envisagerais pas d’utiliser un ORM, c’est lorsque vous exécutez une application de type reporting/tableau de bord sans mise à jour ou lorsque vous créez une application destinée uniquement à effectuer des opérations de maintenance des données brutes sur une base de données.
3) Code soigné/maintenable
De loin, EF bat SQL/sprocs. Comme vos relations sont modélisées, les jointures dans votre code sont relativement peu fréquentes. Les relations des entités sont presque évidentes pour le lecteur pour la plupart des requêtes. Rien de pire que de devoir passer d'un débogage à un autre ou par le biais de plusieurs niveaux SQL/intermédiaire afin de comprendre ce qui se passe réellement dans vos données. EF introduit votre modèle de données dans votre code de manière très puissante.
4) Flexibilité
Les procédures stockées et le SQL brut sont plus "flexibles". Vous pouvez exploiter sprocs et SQL pour générer des requêtes plus rapides pour les cas particuliers impairs. Vous pouvez également exploiter la fonctionnalité de base de données native plus facilement que vous ne le pouvez avec ORM.
5) Globalement
Ne vous laissez pas prendre à la fausse dichotomie de choisir un ORM ou d'utiliser des procédures stockées. Vous pouvez utiliser les deux dans la même application, et vous devriez probablement. Les opérations volumineuses doivent aller dans les procédures stockées ou dans le code SQL (qui peut être appelé par le EF), et EF devrait être utilisé pour vos opérations CRUD et la plupart des besoins de votre niveau intermédiaire. Peut-être choisiriez-vous d'utiliser SQL pour rédiger vos rapports. Je suppose que la morale de l'histoire est la même que depuis toujours. Utilisez le bon outil pour le travail. Mais le problème, EF est très bon de nos jours (à partir de .NET 4.0). Passez du temps à le lire et à le comprendre en profondeur et vous pourrez créer facilement des applications étonnantes et hautes performances.
EDIT: EF 5 simplifie un peu cette partie avec les requêtes LINQ compilées automatiquement , mais pour les applications très volumineuses, vous devez absolument tester et analyser ce qui vous convient le mieux dans la réalité. monde.
Procédures stockées:
(++)
- Grande flexibilité
- Contrôle total sur SQL
- La plus haute performance disponible
(-)
- Nécessite une connaissance de SQL
- Les procédures stockées sont hors du contrôle de source
- Quantité substantielle de "se répéter" tout en spécifiant les mêmes noms de table et de champ. Risque élevé de casser l'application après avoir renommé une entité de base de données et en avoir oublié certaines références.
- Développement lent
ORM:
(+)
- Développement rapide
- Le code d'accès aux données est maintenant sous contrôle de source
- Vous êtes isolé des modifications dans la base de données. Si cela se produit, il vous suffit de mettre à jour votre modèle/mappage à un seul endroit.
(-)
- La performance peut être pire
- Pas ou peu de contrôle sur le SQL produit par l'ORM (peut être inefficace ou pire bogué). Peut-être besoin d'intervenir et de le remplacer par des procédures stockées personnalisées. Votre code sera désordonné (certains LINQ dans le code, certains SQL dans le code et/ou dans la base de données hors du contrôle de code source).
- Comme toute abstraction peut produire des développeurs "de haut niveau" n'ayant aucune idée de la façon dont cela fonctionne sous le capot
Le compromis général consiste à avoir une grande flexibilité et à perdre beaucoup de temps par rapport au fait d’être limité dans ce que vous pouvez faire mais de le faire très rapidement.
Il n'y a pas de réponse générale à cette question. C'est une question de guerres saintes. Cela dépend également d'un projet et de vos besoins. Choisissez ce qui vous convient le mieux.
votre question est essentiellement O/RM vs main écrit SQL
Utilisation d'un ORM ou d'un SQL simple?
Jetez un coup d’œil à quelques-unes des autres solutions O/RM disponibles, L2S n’est pas le seul (NHibernate, ActiveRecord).
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
pour répondre aux questions spécifiques:
- Dépend de la qualité de la solution O/RM, L2S est très bon pour générer du SQL.
- Ceci est normalement beaucoup plus rapide en utilisant un O/RM une fois que vous maîtrisez le processus
- Le code est également généralement plus soigné et plus facile à gérer
- Le SQL direct vous apportera bien sûr plus de flexibilité, mais la plupart des O/RM peuvent effectuer toutes les requêtes sauf les plus compliquées.
- Globalement, je suggérerais d'aller avec un O/RM, la perte de flexibilité est négligeable
LINQ-to-SQL est une technologie remarquable, très simple à utiliser, qui génère généralement de très bonnes requêtes vers le back-end. LINQ-to-EF devait le supplanter, mais historiquement, il était extrêmement difficile à utiliser et générait un code SQL bien inférieur. Je ne connais pas l'état actuel des choses, mais Microsoft a promis de migrer tout le bien de L2S vers L2EF, alors peut-être que tout va mieux maintenant.
Personnellement, je n'aime pas vraiment les outils ORM (voir ma diatribe ici pour les détails), et je ne vois donc aucune raison de préférer L2EF, car L2S me fournit tout ce dont je m'attendais de la part d'une couche d'accès aux données. En fait, je pense même que les fonctionnalités de L2S telles que les mappages fabriqués à la main et la modélisation par héritage ajoutent une complexité totalement inutile. Mais c'est juste moi. ;-)
Vous voudrez peut-être envisager une toute nouvelle approche si vous recherchez la puissance et les performances des procédures stockées et le développement rapide que fournissent des outils tels qu'Entity Framework.
J'ai pris SQL + pour un essai sur un petit projet, et c'est vraiment quelque chose de spécial. Vous ajoutez en gros ce qui revient à des commentaires dans vos routines SQL, et ces commentaires fournissent des instructions à un générateur de code, qui crée ensuite une bibliothèque de classes orientée objet vraiment intéressante basée sur la routine SQL proprement dite. Un peu comme cadre d'entité à l'inverse.
Les paramètres d'entrée deviennent une partie d'un objet d'entrée, les paramètres de sortie et les jeux de résultats deviennent une partie d'un objet de sortie et un composant de service fournit les appels de méthode.
Si vous souhaitez utiliser des procédures stockées tout en souhaitant un développement rapide, jetez un coup d'œil à ces éléments.