Devrais-je utiliser les classes Entity Framework, DataSet ou Custom?

c# dataset entity-framework wcf

Question

J'ai vraiment du mal à vivre ici. Je dois concevoir une "application de bureau" qui utilisera WCF comme canal de communication. C'est une application multiniveau (la base de données et le serveur d'applications sont identiques, le client passe par le nuage Internet).

L'application est un peu complexe (en termes de code SQL et de logique de code), puis les applications LOB habituelles, mais le concept est le même: lecture à partir de la base de données, mise à jour vers la base de données, gestion de la concurrence, etc. Mon problème est que maintenant, avec Entity Framework Lorsque je suis ouvert, je ne peux pas décider de la marche à suivre: Devrais-je utiliser Entity Framework, Dataset ou Custom Classes?

Si je comprends bien, Entity Framework créera également le mappage des objets de mes tables de base de données avec les scripts CRUD. C’est très bien pour un simple CRUD, mais la plupart du temps, le "Select" est complexe et nécessite un code SQL personnalisé. Je comprends que je peux utiliser les procédures stockées dans EF (je n'aime pas SP btw, je ne sais pas pourquoi, j'aime bien coder mon code SQL dans le DAL à la main, je me sens plus en sécurité et plus à l'aise de cette façon).

Avec DataSet, je vais utiliser mes instructions SQL personnalisées et les renseigner dans l’ensemble de données. Avec les classes personnalisées (objets pour les tables de base de données), je vais renseigner mes SQL personnalisés sur ces classes personnalisées (collections et listes, etc.). Je veux utiliser EF, mais je ne me sens pas à l'aise pour déployer une application dont je n'ai pas écrit le code SQL et que je ne peux pas voir dans le code. Est-ce que j'ai râté quelque chose.

Toute aide à cet égard serait grandement appréciée.

Xeshu

Réponse acceptée

Je suis d'accord avec Marc G. 100% - Les ensembles de données sont nuls, en particulier dans un scénario WCF (ils ajoutent beaucoup de temps système pour la manipulation des données en mémoire) - n'utilisez pas ceux-ci. Elles sont acceptables pour les débutants et les applications de bureau à deux niveaux à petite échelle peut-être, mais je ne les utiliserais pas dans une application sérieuse et professionnelle.

En gros, votre question se résume à la façon dont vous transformez vos lignes de la base de données en quelque chose que vous pouvez distant via WCF. Cela signifie une forme de mappage - soit vous le faites vous-même, en utilisant DataReaders, puis en plaçant toutes les données dans des classes WCF [DataContract] - vous pouvez le faire, vous donne le contrôle ultime, mais c'est aussi fastidieux, lourd et erroné - enclin.

Ou vous laissez un ORM prêt à l'emploi s'occuper de ce travail fastidieux - faites votre choix parmi Linq-to-SQL (excellent, facile à utiliser, flexible, mais SQL Server uniquement), EF v4 (sorti en mars 2010). très prometteur, très flexible) ou tout autre ORM, vraiment - ce qui convient le mieux à vos besoins.

Subsonic 3.0 et NHibernate (parmi beaucoup d'autres) figurent parmi les autres concurrents sérieux dans le domaine ORM.

Pour résumer:

  • oublier les jeux de données
  • soit vous avez le contrôle à 100% et la correspondance entre SQL et vos objets vous-même
  • vous laissez un ORM compétent gérer cela (Linq-to-SQL, EF v4, Subsonic, NHibernate et autres) - lequel importe peu, c’est-à-dire qu’il s’agit aussi de préférences personnelles et de style de codage

Réponse d'expert

Je ne peux pas préconiser des ensembles de données, en particulier dans un environnement SOA tel que WCF. Cela fonctionnera, mais pour la plupart des raisons erronées. Ils ne sont tout simplement pas portables et l'OMI ne «travaille» pas vraiment au-delà des limites de service. Bien sûr, IMO ils ne fonctionnent pas dans la plupart des autres scénarios aussi ;-p

Cela revient donc à la quantité de plomberie que vous voulez faire. La plupart des ORM créeront des types sérialisables par WCF; Personnellement , j'utiliser LINQ to SQL au moment; il est à la fois plus simple et plus complet que EF, bien que EF 4.0 soit censé être bien meilleur que EF dans 3.5sp1. Vous pouvez utiliser TSQL personnalisé (via ExecuteQuery , qui effectue toujours le mappage sur des objets), mais j'ai tendance à utiliser SPROC (pour les requêtes complexes) ou les requêtes générées par LINQ (pour les requêtes simples).

Écrire les types vous-même convient également, et fonctionnera avec NHibernate, etc. Tellement d'options.



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow