Dataset vs Entity Framework avec des procédures stockées

L'ensemble de la question a été réécrit pour être plus clair..

La conception de nouveaux projets:

  1. Sql Server 2012
  2. Visual Studio 2012 .Net 4.5
  3. Logique d'entreprise sera mis en œuvre dans les procédures stockées
  4. ASP.Net Webforms
  5. WCF SAVON de Service Web XML pour communiquer avec la base de données à l'aide fournie procédures stockées par DBA
  6. Cadre de l'entité ou d'un Dataset

Ici, je peux utiliser l'ensemble de données - pas de problème, mais je voudrais savoir l'avantage de l'Entity Framework plus de données dans des explications plus détaillées. J'ai lu des articles sur entity framework, et j'ai vu des gens qui avaient une meilleure expérience de l'utilisation de EF sur dataset en raison des raisons suivantes.

Je voudrais savoir si ce sont toujours les avantages que je peux obtenir à l'aide de EF dans mon cas - de la base de données des demandes connexes sont toujours fait avec des procédures stockées:

  1. EF est beaucoup plus propre et beaucoup plus facile à maintenir et programme contre.
    Les requêtes contre l'EF ObjectContext sont toujours exécutées sur la base de données
  2. Parce que la correspondance entre vos objets et votre base de données est spécifié de manière déclarative au lieu de dans le code, si vous avez besoin de changer votre schéma de base de données, vous pouvez minimiser l'impact sur le code à modifier dans vos applications, de sorte que le système fournit un niveau d'abstraction qui permet d'isoler l'application à partir de la base de données. L'EF peut donc remplacer une grande partie du code de vous éviter d'avoir à écrire et à maintenir vous-même.(Si la procédure stockée design a été changé?)
  3. L'EF a été spécialement structuré pour séparer le processus de cartographie des requêtes/formation des résultats de la construction d'objets et de suivi des modifications.
  4. Ensembles de données sucer, surtout dans un WCF scénario (ils ajoutent beaucoup de frais généraux pour la manipulation de données en mémoire de manipulation) -> signifie EF avec WCF est de mieux en performance ?
Quelle est la question?
Lire ceci: blog.stackoverflow.com/2011/08/gorilla-vs-shark et aller avec EF
Va avec EF est toujours un meilleur choix de plus de Dataset?
apparemment vous n'avez pas lu le post de blog lié
eh bien... oui je suis d'accord c'est un gorilla vs shark comme question, mais vous avez dit que gorilla gagne ici en disant "EF". pourquoi EF? tout simplement parce que l'ensemble de données est une vieille technologie? Microsoft mettra l'accent sur EF pas Dataset? L'ORM est mieux même si je travaille avec des procédures stockées? Je dois convaincre mon équipe pour aller avec EF avec des explications plus détaillées.

OriginalL'auteur devphil | 2013-01-03

  1. 11

    1. EF est beaucoup plus propre et beaucoup plus facile à maintenir et programme de contre ->> pouvez-vous développer?.. est-ce à cause de #2 ci-dessous?

    EF est un Object Relational Mapper (ORM) et permettra de générer automatiquement les objets liés à votre schéma de base de données comme indiqué dans le #2. EF est un out-of-box abstraction pour votre couche d'accès aux données et dans la version actuelle met en œuvre un modèle de référentiel. Cela vous donne des avantages tels que LINQ, le graphe d'objet les opérations CRUD, et ce que l'équipe EF considère comme la meilleure pratique pour l'accès aux données via .NET.

    L'out-of-box fonctionnalité et la facilité d'intégration avec la base de données (plus précisément SQL Server) peut fournir plus facile à maintenir et programme contre. Cependant, il existe des situations où l'utilisation d'un ORM peut ne pas être la meilleure option et vous devez utiliser un jugement prudent. Voici quelques scénarios de penser à ne pas utiliser un ORM (surtout quand votre équipe manque de connaissances actuelles de l'EF): un nombre limité de requêtes de données, la non-application complexe, confortable écrit ou à l'aide de votre couche d'accès aux données, votre date d'échéance est agressif, etc. Voir autres options que j'ai noté ci-dessous.

    2. Si vous avez besoin de changer votre schéma de base de données, vous pouvez minimiser l'impact sur le code à modifier dans vos applications ->> que faire si les paramètres et les champs renvoyés d'une procédure stockée sont-elles changé? EF toujours de minimiser l'impact?

    Oui, EF génère basé sur fichier EDMX qui est tout simplement un fichier XML de votre schéma de base de données. Cela inclut la mise à jour des objets de la carte à vos procédures stockées (NOTE: ceci n'est pas applicable si l'aide de premier code jusqu'à ce que EF6 est libéré). Vous pouvez modifier une procédure stockée et EF pouvez prendre le schéma de mise à jour et mise à jour de votre code. Cependant, vous devrez corriger votre code où vous avez appelé EF procédures stockées, les méthodes et les paramètres ont changé. Vous pouvez également utiliser quelque chose de LINQ to SQL si vous êtes à l'aise avec EF, qui fournira des appels de procédures stockées en tant que méthodes de l'objet.

    3. Ensembles de données sucer, surtout dans un WCF scénario (ils ajoutent beaucoup de frais généraux pour la manipulation de données en mémoire de manipulation) ->> Pouvez-vous expliquer plus?

    "Ensembles de données sucer" est évidemment une déclaration générique. Vous utilisez des ensembles de données pour ce qu'ils sont destinés pour ce qui est de traiter avec les données en mémoire à l'aide .NET. Depuis les jeux de données sont en mémoire, ils sont considérés comme inefficaces en en faisant de simples opérations CRUD. Il est recommandé d'utiliser des procédures stockées et les lecteurs de données (assurez-vous de les fermer quand fait la lecture des données) pour l'efficacité des lectures de données avec SQL base de données.

    Il y a d'autres options en plus EF:

    1. Le faire vous-même - d'Écrire des procédures stockées, les données d'utilisation de lecteurs, et la carte des objets POCO

    2. Utiliser une Bibliothèque Dynamique - Dapper, ServiceStack ORM Lite, Simple POCO, de Données Simple, Massive

    3. Utiliser LINQ to SQL - plus Léger de poids de couche d'accès aux données (Uniquement pour SQL Server )

    4. Autres Orm - NHibernate est l'un des meilleurs choix.

    OriginalL'auteur Jonathan Harrison

  2. 2

    C'est pour répondre à la réponse de Jonathan sur un jeu de données. Parce qu'un commentaire permet trop court le contenu, donc je l'ai mis comme réponse.

    C'est vieux, mais jusqu'à maintenant, avec EF6 et EF dotnet de base , je vois que c'est toujours valable pour débattre de ce point.

    Je suis la recherche des avis sur ce sujet et a finalement atteint ce post. Honnêtement, je suis assez en désaccord avec Jonathan sur un jeu de données.

    De réponse à "Depuis les jeux de données sont en mémoire, ils sont considérés comme inefficaces en en faisant de simples opérations CRUD", je crois que EF est DbContext est dans la mémoire trop, et hors-ligne de traitement de données n'est pas conçu uniquement pour le jeu de données, mais aussi LinQ2SQL et EF. Simple opération CRUD peut être fait avec DataTableAdapter et CommandBuilder, vous n'avez pas besoin d'écrire seul des instructions SQL. Jeu de données est une partie de ADO.NET nous ne pouvons pas dire ADO.NET recommande Procédure Stockée ou d'autre chose, elle doit prendre en charge tous les moyens d'accès à la base de données, en fait DataSet n'a pas accès de base de données, DataTableAdapter, DataReader, DbCommand faire.

    Si vous utilisez DataSet Typé de Visual Studio, vous allez le voir de loin supérieure à celle de l'EF dans une Procédure Stockée de cartographie et de traitement par lots. Mon projet a 5000 procédures stockées et de la cartographie pour EF est douloureux, EF jette de nombreux types d'erreurs si les déclarations ne sont pas pris en charge par EF. D'autre part, DataSet Typé permet de contrôler de très petits détails de la procédure stockée de cartographie, de le plier pour votre besoin. Sur le lot d'opérations, de Table, de cartes vous permet de contrôler le nombre de déclarations peut être envoyé à la fois, Comment sur EF? 1 par 1, imaginez que vous devez importer 10000 enregistrements, j'ai fait une comparaison pour ce scénario, il n'y a pas moyen de le rendre rapide en EF. Si la procédure stockée est changé, donnez-moi 30 secondes à fixer le jeu de données, soit à la régénération ou à traiter manuellement. Vous le trouverez pas plus vite en EF.

    Il n'y a aucun moyen EF est plus rapide que ADO.NET en utilisant un jeu de données. EF ajoute beaucoup la surcharge de l'analyse Expressionarborescence, l'évaluer, de la génération de SQL instruction avant d'utiliser ADO.NET pour mettre à jour la base de données, en vertu de l'EF du capot est ADO.NET.

    La seule chose que j'ai trouvé gênant avec DataSet est que DataRow n'est pas POCO. Il est difficile de sérialiser, fait sucer dans WCF lorsque vous avez à faire correspondre à DataContract, vous pouvez utiliser EF du POCO comme contrat de données directement.

    Pour les projets de ceux que vous devrez faire face à beaucoup de données, mise à jour en bloc, procédures stockées, rester à l'écart de EF. J'ai donné EF trop nombreux essais pour jouer avec des projets d'Entreprise, mais finalement, j'ai dû utiliser DataSet Typé pour tous. Je suis toujours à la recherche d'opinions, parce que j'ai encore l'espoir que l'EF sera en mesure de répondre à mon besoin. J'aime la simplicité de l'EF, mais elle est encore trop jeune comparant à DataSet Typé.

    Khoa - Apprécier les commentaires mais pour être clair, je n'étais PAS en précisant les jeux de données sont inférieures à EF ou de dire d'utiliser EF, en fait, je ne préfère pas les EF et qui n'est pas de même de la comparaison. Je m'adressais les avantages/inconvénients de l'EF afin que le lecteur puisse décider de ce que l'outil fonctionne compte tenu de l'emploi. Le point concernant les ensembles de données étant inefficace est lié à une application web (ou WCF) et, généralement, un ensemble de données est trop pour le CRUD en raison d'une demande/réponse du service (par exemple, je préfère un modèle CQRS à l'aide des Otd et Dapper). Jeu de données primaire de cas d'utilisation sont pour les applications nécessitant une déconnexion en mémoire de manipulation de données.
    Pour faire bref, mon point est: "Si vous avez un simple CRUD application, vous pouvez aller avec EF. Si c'est l'application avec de lourdes accès aux données (mise à jour en bloc, procédures stockées), puis aller avec la chose qui prend en charge ces bien".

    OriginalL'auteur Khoa Nguyen