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

Question

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

1. Performance
2. La vitesse de développement
3. Propre, intuitive, facile à gérer le code
4. La flexibilité
5. Ensemble

J'aime mon SQL et ont donc toujours été un die-hard fan de ADO.NET et des procédures stockées, mais j'ai récemment eu un jeu avec Linq to SQL et a été emporté par la rapidité avec laquelle j'ai écrit mon DataAccess couche et ont décidé de passer un peu de temps à comprendre réellement ce soit Linq to SQL ou EF... ou aucun des deux?

Je veux juste vérifier, qu'il n'y a pas une grande faille dans un de ces technologies qui le rendrait mon temps de recherche inutile. E. g. la performance est terrible, c'est cool pour des applications simples, mais ne peut vous prendre jusqu'à présent.

Mise à jour: Vous pouvez vous concentrer sur EF VS L2 VS SPs plutôt que de l'ORM VS SPs. Je suis principalement intéressé par EF VS L2S. Mais je suis désireux de les avoir comparés stockées procs trop depuis la plaine SQl est quelque chose que je sais beaucoup de choses sur.

Answer 1

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

1) la Performance

C'est difficile de répondre. Pour la plupart entité unique des opérations (CRUD), vous trouverez à peu près les mêmes performances avec tous les trois technologies. Vous devez savoir comment EF et Linq to SQL travail en vue de les utiliser à leur maximum. Pour un volume élevé d'opérations comme les requêtes d'interrogation, vous voudrez peut-EF/L2S "compiler" votre entité de la requête telles que le cadre n'est pas constamment régénérer le SQL, ou vous pouvez rencontrer des problèmes d'évolutivité. (voir modifications)

En vrac, les mises à jour lorsque vous mettez à jour des quantités massives de données, brutes SQL ou une procédure stockée effectuera toujours mieux qu'un ORM solution parce que vous n'avez pas à rassembler les données sur le fil de la moraine d'oak ridges à effectuer des mises à jour.

2) la Vitesse de Développement

Dans la plupart des scénarios, EF souffler nu/SQL stockées procs quand il s'agit de la vitesse de développement. L'EF concepteur pouvez mettre à jour votre modèle à partir de votre base de données de l'évolution de la (sur demande), de sorte que vous ne courez pas dans les problèmes de synchronisation entre l'objet de votre code et de votre code de base de données. La seule fois où je ne serait pas envisager l'utilisation d'un ORM, c'est quand vous faites un reporting/tableau de bord type d'application où vous n'avez pas à faire toute la mise à jour, ou lorsque vous êtes en train de créer une application juste, données brutes des opérations de maintenance sur une base de données.

3) Neat/code Maintenable

Mains vers le bas, EF beats SQL/sprocs. Parce que vos relations sont modélisés, les jointures de votre code sont relativement peu fréquents. Les relations de ces entités sont presque évident pour le lecteur que pour la plupart des requêtes. Rien n'est pire que d'avoir à passer de niveau de niveau de débogage ou par le biais de multiples SQL/niveau intermédiaire afin de comprendre ce qui se passe réellement à vos données. EF apporte à votre modèle de données dans votre code dans une manière très puissante.

4) la Flexibilité

Stockées procs et SQL brut sont plus "souple". Vous pouvez tirer parti de sprocs et SQL pour générer des requêtes plus rapides pour l'étrange cas spécifique, et vous pouvez tirer parti des indigènes DB fonctionnalités plus facile que vous pouvez avec et ORM.

5) dans l'Ensemble

Ne pas se laisser prendre dans la fausse dichotomie de choisir un ORM vs l'utilisation de procédures stockées. Vous pouvez utiliser les deux dans la même application, et vous devriez probablement. De grandes opérations en bloc devrait aller dans les procédures stockées ou SQL (ce qui peut être appelé par le EF), et de l'EF doit être utilisé pour vos opérations CRUD et la plupart de votre moyen de palier les besoins. Peut-être vous choisissez d'utiliser SQL pour la rédaction de vos rapports. Je crois que la morale de l'histoire est la même comme elle l'a toujours été. Utiliser le bon outil pour le travail. Mais la vérité est, EF est très bon aujourd'hui (comme d' .NET 4.0). Passer du temps réel, la lecture et la compréhension en profondeur et vous pouvez créer de magnifiques, de haute performance des applications avec facilité.

EDIT: EF 5 simplifie cette partie un peu avec compilation automatique des Requêtes LINQ, mais pour de vrai volume élevé des trucs, vous aurez certainement besoin de tester et d'analyser ce qui convient le mieux pour vous dans le monde réel.

Answer 2

votre question est fondamentalement O/RM vs écrit à la main SQL

http://stackoverflow.com/questions/494816/using-an-orm-or-plain-sql

Jetez un oeil à certains de l'autre O/RM solutions là-bas, L2 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 l'O/RM solution, L2S est assez bon dans la génération de SQL
2. Normalement, c'est beaucoup plus rapide en utilisant un O/RM une fois que vous grok le processus
3. Le Code est aussi généralement beaucoup plus propre et plus facile à gérer
4. Droite SQL de cours obtiennent plus de souplesse, mais la plupart des O/RM ne peut faire tout, mais la plupart des requêtes compliquées
5. Globalement, je suggère d'aller avec un O/RM, la flexibilité de la perte est négligeable

Answer 3

LINQ-to-SQL est un élément remarquable de la technologie, qui est très simple à utiliser, et par la grande et génère de très bonnes requêtes à l'extrémité arrière. LINQ-to-EF a été désignée pour la remplacer, mais, historiquement, a été très maladroit à utiliser et généré de loin inférieure SQL. Je ne connais pas l'état actuel des choses, mais Microsoft a promis de migrer l'ensemble de la bonté de L2S dans L2EF, donc c'est peut-être mieux maintenant.

Personnellement, j'ai une sainte horreur des outils ORM (voir ma diatribe ici pour les détails), et donc je ne vois pas de raison de privilégier L2EF, depuis L2S donne-moi tout ce que je jamais s'attendre à avoir besoin d'une couche d'accès aux données. En fait, je pense même que L2S des fonctionnalités telles que fabriquées à la main mappages et à l'héritage de la modélisation complètement inutile d'ajouter de la complexité. Mais c'est juste moi. ;-)

Answer 4

Je pense que EF est considéré comme plus approprié pour les solutions d'Entreprise lors de LINQ to SQL est mieux pour les petites solutions.

J'aime EF pour son soutien de Procédures Stockées pour l'insertion/mise à jour/suppression d'entités. (Je suis en utilisant ce modèle T4 de les générer à partir de l' .fichier edmx)