Entity Framework VS LINQ to SQL VS ADO.NET avec des procédures stockées? [fermé]

430

Comment évalueriez-vous chacun d'eux en termes de:

  1. Performance
  2. Vitesse de développement
  3. Code soigné, intuitif et maintenable
  4. Souplesse
  5. Global

J'aime mon SQL et j'ai donc toujours été un fan inconditionnel d'ADO.NET et des procédures stockées, mais j'ai récemment joué avec Linq to SQL et j'ai été époustouflé par la rapidité avec laquelle j'écrivais ma couche DataAccess et j'ai décidé de dépenser quelque temps vraiment comprendre soit Linq à SQL ou EF ... ou ni l'un ni l'autre?

Je veux juste vérifier qu'il n'y a pas une grande faille dans aucune de ces technologies qui rendrait mes recherches inutiles. Par exemple, les performances sont terribles, c'est cool pour des applications simples, mais cela ne peut vous mener que si loin.

Mise à jour: pouvez-vous vous concentrer sur les EF VS L2S VS SP plutôt que sur les ORM VS SP. Je suis principalement intéressé par EF VS L2S. Mais je tiens également à les comparer aux proc stockés, car le langage SQl simple est quelque chose que je connais beaucoup.

sql linq-to-sql entity-framework ado.net linq-to-entities BritishDeveloper
la source
94
pas constructif et pourtant autant de votes positifs? ...;)
BritishDeveloper
34
Je ne vois pas pourquoi quelqu'un a marqué cela comme non constructif. Cela me semble vraiment bon. +1 de moi.
Thanushka
10
À mon avis, c'est une excellente question. Personnellement, j'ai remarqué Entity Framework et tous les ORM similaires plus lentement que le code ADO.Net simple / simple. J'ai fait ce test il y a 2 ans, puis encore une semaine. Je ne sais pas comment LINQ to SQL se compare à EF. Mais ADO.Net sera toujours le meilleur en termes de performances. Si vous souhaitez gagner du temps de développement, Entity Framework est un bon outil, mais certainement pas lorsque les performances sont votre principale préoccupation.
Sunil
2
@Timeless: Il y a une tendance à ne pas se fier aux mécanismes de base de données. Chaque moteur de base de données possède son propre langage de procédure stockée, il y a donc un apprentissage supplémentaire. 99,9% des développeurs peuvent compter sur des ORM, qui produisent un assez bon code et créent automatiquement du SQL. La différence de performance est marginale en cas de CRUD simple. Les procédures stockées sont plus difficiles à développer et à maintenir. Il y a quelques années, quand il n'y avait pas d'ORM et rien n'était généré comme par magie et automatiquement de la base de données. L'écriture de SP n'était pas si longue, car elle était alternative à l'écriture d'instructions SQL dans l'application.
LukLed
4
@Sunil est correct, mais pas assez verbeux. Le problème est que tout le monde pense que leur principale préoccupation est la performance des applications. Lorsque je parle d'applications qui nécessitent des performances optimales, je pense à des MMO C ++ inconditionnels ou à des transactions de bases de données clientes à volume élevé dans les millions. Vous devriez vraiment vous concentrer sur des principes orientés objet comme la maintenabilité , la lisibilité , l'ignorance de la persistance et la séparation de la logique du domaine . Surtout lorsque l'augmentation des performances est mineure au mieux ou inexistante dans de nombreux cas.
Suamere

Réponses:

430

Tout d'abord, si vous démarrez un nouveau projet, optez pour Entity Framework ("EF") - il génère désormais beaucoup mieux SQL (plus comme Linq to SQL) et est plus facile à maintenir et plus puissant que Linq to SQL (" L2S "). Depuis la sortie de .NET 4.0, je considère Linq to SQL comme une technologie obsolète. MS a été très ouvert à l'idée de ne pas poursuivre le développement de L2S.

1) Performance

C'est difficile à répondre. Pour la plupart des opérations sur une seule entité ( CRUD ), vous trouverez à peu près des performances équivalentes avec les trois technologies. Vous devez savoir comment EF et Linq to SQL fonctionnent pour 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 n'ait pas à régénérer constamment le SQL, ou vous pouvez rencontrer des problèmes d'évolutivité. (voir modifications)

Pour les mises à jour groupées où vous mettez à jour d'énormes quantités de données, le SQL brut ou une procédure stockée fonctionnera toujours mieux qu'une solution ORM car vous n'avez pas besoin de marshaler les données par câble vers l'ORM pour effectuer des mises à jour.

2) Vitesse de développement

Dans la plupart des scénarios, EF soufflera les procs SQL / stockés nus en ce qui concerne 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), afin que vous ne rencontriez pas de problèmes de synchronisation entre votre code objet et le code de votre base de données. La seule fois où je n'envisagerais pas d'utiliser un ORM, c'est lorsque vous effectuez une application de type rapport / tableau de bord où vous ne faites aucune mise à jour, ou lorsque vous créez une application juste pour effectuer des opérations de maintenance de données brutes sur une base de données.

3) Code ordonné / maintenable

De loin, EF bat SQL / sprocs. Parce que 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 d'avoir à passer d'un débogage de niveau à l'autre ou à travers plusieurs niveaux SQL / intermédiaire afin de comprendre ce qui se passe réellement dans vos données. EF apporte votre modèle de données dans votre code d'une manière très puissante.

4) Flexibilité

Les proc stockés et le SQL brut sont plus "flexibles". Vous pouvez tirer parti des sprocs et de SQL pour générer des requêtes plus rapides pour les cas spécifiques impairs, et vous pouvez tirer parti des fonctionnalités de base de données natives plus facilement que vous ne le pouvez avec ORM.

5) Global

Ne vous laissez pas prendre dans la fausse dichotomie de choisir un ORM vs d'utiliser des procédures stockées. Vous pouvez utiliser les deux dans la même application, et vous devriez probablement le faire. Les grandes opérations en bloc doivent aller dans des procédures stockées ou SQL (qui peuvent en fait être appelées par l'EF), et EF doit être utilisé pour vos opérations CRUD et la plupart des besoins de votre niveau intermédiaire. Vous pourriez peut-être choisir d'utiliser SQL pour rédiger vos rapports. Je suppose que la morale de l'histoire est la même qu'elle a toujours été. Utilisez le bon outil pour le travail. Mais le maigre est que EF est très bon de nos jours (à partir de .NET 4.0). Passez un peu de temps à lire et à comprendre en profondeur et vous pouvez facilement créer des applications incroyables et hautes performances.

EDIT : EF 5 simplifie un peu cette partie avec les requêtes LINQ compilées automatiquement , mais pour des choses vraiment volumineuses, vous aurez certainement besoin de tester et d'analyser ce qui vous convient le mieux dans le monde réel.

Dave Markle
la source
35
Réponse absolument brillante. J'utilise désormais EF pour développer rapidement une application. Si les performances deviennent un problème, des proc stockés seront apportés pour refactoriser les requêtes EF mal exécutées. Merci!
BritishDeveloper
17
@BritishDeveloper: N'oubliez pas non plus le pouvoir d'utiliser les vues également. Nous avons eu beaucoup de succès en définissant quelques vues dans nos projets L2S et en les exploitant là où le framework semble écrire des requêtes médiocres. De cette façon, nous obtenons tous les avantages de l'utilisation du framework avec tous les avantages de l'écriture de notre propre SQL.
Dave Markle
5
J'utilise également Views;) Plus comme solution de contournement pour la limitation db non croisée d'EF. Bonne idée à utiliser pour l'optimisation cependant. Merci
BritishDeveloper
5
Certainement une excellente réponse. Je voulais juste ajouter une observation que j'avais dans ma propre expérience avec L2S vs EF4. Échangé de L2S -> EF4 après avoir réalisé que nous utilisions peut-être plusieurs RDMBS différents ... mais, tout en exécutant MSSQL, la baisse de performances s'est principalement produite dans la zone GUI de mon application. La liaison de données à l'ensemble de résultats dans L2S était beaucoup plus rapide que EF4. C'est exactement la même requête sur la même base de données exacte. Une chose à noter ici est que je retourne plus de 90k disques, donc la différence était assez évidente. Peut-être que sur les petits ensembles, ce n'est pas un problème? Je ne sais pas comment cela évoluerait avec des sites à haut vol ...
bbqchickenrobot
5
Bonne réponse. Je viens de passer 4 semaines à travailler avec LINQ-to-Entities, en essayant de tout ranger, avant de réaliser enfin que vous avez besoin de SQL natif pour des choses comme la copie en bloc, la suppression en bloc, la suppression ultra rapide des doublons d'une base de données, etc. bon outil pour le travail, il n'y a aucune honte à mélanger SQL natif avec le framework LINQ to Entities.
Contango
93

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 contrôle de source
  • Beaucoup de "se répéter" tout en spécifiant les mêmes noms de table et de champ. Il y a de fortes chances de casser l'application après avoir renommé une entité de base de données et manquer des références à celle-ci quelque part.
  • Développement lent

ORM:

(+)

  • Développement rapide
  • Le code d'accès aux données est désormais sous contrôle de source
  • Vous êtes isolé des changements dans DB. Si cela se produit, il vous suffit de mettre à jour votre modèle / mappage en un seul endroit.

(-)

  • Les performances peuvent être pires
  • Pas ou peu de contrôle sur SQL produit par l'ORM (peut être un buggy inefficace ou pire). Pourrait avoir besoin d'intervenir et de le remplacer par des procédures stockées personnalisées. Cela rendra votre code désordonné (certains LINQ dans le code, certains SQL dans le code et / ou dans la base de données hors contrôle de source).
  • Comme toute abstraction peut produire des développeurs "de haut niveau" n'ayant aucune idée de comment cela fonctionne sous le capot

Le compromis général est entre avoir une grande flexibilité et perdre beaucoup de temps par rapport à être limité dans ce que vous pouvez faire mais 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 aussi d'un projet à portée de main et de vos besoins. Choisissez ce qui vous convient le mieux.

AGuyCalledGerald
la source
47
Je ne pense pas que les points concernant le contrôle des sources soient pertinents. Le schéma de la base de données, les procédures stockées, les FDU, etc. peuvent tous être et doivent être sous contrôle de source.
Lee Gunn
15
+1 pourAs any abstraction can produce "high-level" developers having no idea how it works under the hood
nawfal
3
D'accord, l'argument de contrôle de source est incorrect. Nous stockons toujours nos scripts de création de base de données dans svn. Comment pouvez-vous même garder la base de données hors du contrôle des sources lors du développement d'une application de base de données?
Wout
3
EF n'est pas vraiment adapté à la haute disponibilité et aux hautes performances, je ne suis pas un type DBA mais je ne vois pas ce qu'EF offre qui facilite le codage.
Jamie
4
Ainsi, nous abandonnons la flexibilité, le contrôle total et les performances pour un "développement rapide" et évitons les changements de code si la DB change. Cela me semble être une pure paresse.
user2966445
18

votre question est essentiellement O / RM vs écriture manuscrite SQL

Vous utilisez un ORM ou du SQL simple?

Jetez un œil à certaines 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:

  1. Dépend de la qualité de la solution O / RM, L2S est assez bon pour générer du SQL
  2. Ceci est normalement beaucoup plus rapide en utilisant un O / RM une fois que vous avez bloqué le processus.
  3. Le code est également généralement beaucoup plus net et plus facile à maintenir
  4. Le SQL simple vous offrira bien sûr plus de flexibilité, mais la plupart des O / RM peuvent faire toutes les requêtes sauf les plus compliquées.
  5. Dans l'ensemble, je suggère d'aller avec un O / RM, la perte de flexibilité est négligeable
Glace noir
la source
@David Merci, mais ce n'est pas ORM vs SQL. Je cherche à passer à ORM et je me demande lequel investir du temps dans l'apprentissage: EF ou L2S (à moins qu'ils ne soient des ordures par rapport aux processus stockés)
BritishDeveloper
1
Je dirais certainement qu'ils ne sont pas des ordures par rapport aux procs stockés, et un avantage secondaire est que vous n'avez pas de code diffusé dans la base de données. Personnellement, j'aime L2S, mais je n'ai pas fait grand chose avec EF à ce stade, et il semble que L2EF va le remplacer, alors j'irais EF. De plus, une fois que vous allez à Linq, vous n'y retournez pas.
BlackICE
13

LINQ-to-SQL est une technologie remarquable qui est très simple à utiliser et qui, dans l'ensemble, génère de très bonnes requêtes vers le serveur principal. LINQ-to-EF devait le remplacer, mais historiquement, il a été extrêmement maladroit à utiliser et a généré un SQL bien inférieur. Je ne connais pas la situation actuelle, mais Microsoft a promis de migrer toutes les qualités de L2S dans L2EF, alors peut-être que c'est mieux maintenant.

Personnellement, j'ai une aversion passionnée pour les outils ORM (voir ma diatribe ici pour les détails), et donc je ne vois aucune raison de favoriser L2EF, car L2S me donne tout ce dont je m'attends à avoir besoin d'une couche d'accès aux données. En fait, je pense même que les fonctionnalités L2S telles que les mappages fabriqués à la main et la modélisation de l'héritage ajoutent une complexité complètement inutile. Mais c'est juste moi. ;-)

Marcelo Cantos
la source
1
L2S est assez bon, mais a l'inconvénient que Microsoft a déclaré qu'il n'allait pas investir beaucoup dans son extension. Vous pouvez voir les résultats de cela déjà dans la dernière version qui n'a que quelques corrections de bogues et une prise en charge des types de données SQL Server 2008 ajoutés.
FinnNk
D'accord, @FinnNk. C'est une triste réalité que l'utilisation de L2S est quelque peu risquée en raison de son statut de paria. Mais s'ils ont vraiment réussi à le faire complètement en faveur de L2EF, je soupçonne fortement qu'il y aurait un chemin de migration, en raison des éléments suivants dont il bénéficie toujours.
Marcelo Cantos
3
Linq to EF est arrivé à maturité et produit désormais du SQL aussi bon que L2S (à partir de .NET 4.0). L2EF est beaucoup plus agréable que L2S de nos jours, car il peut au moins mettre à jour votre modèle à mesure que la base de données change, ce que L2S ne pourrait jamais faire automatiquement. J'aime aussi le fait que vous pouvez mapper de simples relations M: M avec EF en tant que relations sans avoir besoin d'avoir une entité intermédiaire. Cela rend le code beaucoup plus propre.
Dave Markle
2
Merci pour la mise à jour @Dave. Cependant, je ne suis pas d'accord avec le commentaire M: M. Les schémas avec lesquels j'ai travaillé développent presque toujours des attributs supplémentaires sur les tables de jointure. Cela induit un changement structurel du modèle objet, nécessitant beaucoup de retouches de code. Je préférerais de loin aborder la relation intermédiaire de manière explicite.
Marcelo Cantos
1

Il existe une toute nouvelle approche que vous voudrez peut-être envisager si vous recherchez la puissance et les performances des procédures stockées et le développement rapide que fournissent des outils comme Entity Framework.

J'ai pris SQL + pour un essai routier sur un petit projet, et c'est vraiment quelque chose de spécial. Vous ajoutez essentiellement ce qui équivaut à des commentaires à 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 très agréable basée sur la routine SQL réelle. Un peu comme un cadre d'entité similaire à l'envers.

Les paramètres d'entrée font partie d'un objet d'entrée, les paramètres de sortie et les jeux de résultats font 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, mais que vous souhaitez toujours un développement rapide, vous voudrez peut-être jeter un œil à ce truc.

Vincent
la source