Quels sont les arguments CONTRE l'utilisation de EntityFramework? [fermé]

31

L'application que je construis actuellement utilise des procédures stockées et des modèles de classe fabriqués à la main pour représenter des objets de base de données. Certaines personnes ont suggéré d'utiliser Entity Framework et j'envisage de passer à cela car je ne suis pas si loin dans le projet. Mon problème est que je pense que les gens qui défendent EF ne me disent que le bon côté des choses, pas le mauvais côté :)

Mes principales préoccupations sont:

  • Nous voulons une validation côté client à l'aide de DataAnnotations, et il semble que je doive de toute façon créer les modèles côté client, donc je ne suis pas sûr que EF économiserait autant de temps de codage
  • Nous aimerions garder les classes aussi petites que possible lorsque vous passez sur le réseau, et j'ai lu que l'utilisation d'EF inclut souvent des données supplémentaires qui ne sont pas nécessaires
  • Nous avons une couche de base de données complexe qui traverse plusieurs bases de données, et je ne suis pas sûr que EF puisse gérer cela. Nous avons une base de données commune avec des choses comme les utilisateurs, les codes d'état, les types, etc. et plusieurs instances de nos bases de données principales pour différentes instances de l'application. Les requêtes SELECT peuvent interroger et interrogeront toutes les instances des bases de données, mais les utilisateurs ne peuvent modifier que les objets qui se trouvent dans la base de données sur laquelle ils travaillent actuellement. Ils peuvent changer de base de données sans recharger l'application.
  • Les modes objets sont très complexes et il y a souvent pas mal de jointures impliquées

Les arguments pour EF sont les suivants:

  • Accès simultané. Je n'aurais pas à coder les chèques pour voir si l'enregistrement a été mis à jour avant chaque sauvegarde
  • Génération de code. EF peut générer des modèles de classe partiels et des POCO pour moi, mais je ne suis pas certain que cela me ferait vraiment gagner beaucoup de temps car je pense que nous aurions encore besoin de créer les modèles côté client pour la validation et certaines méthodes d'analyse personnalisées.
  • Vitesse de développement car nous n'aurions pas besoin de créer les procédures stockées CRUD pour chaque objet de base de données

Notre architecture actuelle se compose d'un service WPF qui gère les appels de base de données via des procédures stockées paramétrées, des objets POCO qui vont vers / depuis le service WCF et le client WPF, et le client de bureau WPF lui-même qui transforme les POCO en modèles de classe à des fins de validation et Liaison de données.

Donc ma question est, est-ce que EF a raison? Y a-t-il des pièges à propos d'EF que je ne connais pas?

architecture orm entity-framework Rachel
la source
Découvrez cela aussi .. une comparaison des performances et du support LINQ: ormeter.net
M.Sameer

Réponses:

7

J'évaluais récemment Entity Framework et le meilleur endroit que j'ai trouvé pour les problèmes et les fonctionnalités manquantes était: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Les éléments avec le plus de votes:

  1. Prise en charge des énumérations. Celui-ci est assez grand, mais il existe actuellement des solutions de contournement
  2. Génération SQL améliorée. La vitesse est vraiment importante, en particulier pour les applications de niveau entreprise, mais il semble qu'avec EF4, elle s'est beaucoup améliorée
  3. Prise en charge de plusieurs bases de données. Exigence pour toute grande application.

Il existe de nombreux autres problèmes dans la liste des voix utilisateur.

D'un autre côté, je suis assez excité par la prochaine version d'EF 4.1 qui inclura l'approche Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-candidate-available.aspx

Cela peut en fait me pousser à essayer EF dans une application de production.

Mag20
la source
Argument contre: 1er, 2e et 3e: c'est lent !!! Il y a une courbe d'apprentissage (besoin de savoir comment faire une jointure gauche - prend 3 heures pour trouver un moyen de le faire afin qu'une autre personne sache ce qui est fait ...), la pagination dans LINQ au lieu de SQL (par exemple, feches 10 millions de lignes, puis en prend 20 à partir d'un décalage arbitraire, et ensuite vous vous demandez pourquoi c'est si lent) ... Le Repo n'est pas sûr, vous devez l'initier sur une base par requête, et l'initialisation du repo est TRÈS LENT (comme 5 secondes) si vous avez une plus grande base de données (cela signifie 100-200 tables, pas vraiment VRAIMENT grandes).
Quandary
2
@Quandary On dirait que vous exécutez IQueryables (c'est-à-dire en appelant .ToList()ou .ToArray) avant que vos expressions LINQ soient entièrement définies. C'est pourquoi il tire tous les records et le ralentit.
orad
6

Faire une branche par bogue / fonctionnalité avec EF peut être remarquablement douloureux au moment de la fusion. Imaginez que deux branches A et B apportent des modifications à la base de données (ce qui se produira probablement beaucoup au cours des premières étapes d'un nouveau projet).

Vous fusionnez tous les fichiers "normaux" - fichiers cs, etc. Et puis il est temps de fusionner Model.edmx. Et soudain, vous ne fusionnez pas seulement les mappages logiques entre votre modèle d'objet et votre base de données, mais également les positions des tables dans le diagramme d'entités.

La fusion de Model.edmx est si douloureuse que nous avons adopté une méthode assez méchante qui fonctionne:

  • Pendant la fusion, sélectionnez simplement toutes les fusions d'un parent. Ce qui n'a pas d'importance; vous allez bientôt porter un toast au fichier:
  • Rétablissez Model.edmx sur l'un des parents.
  • Migrez votre base de données vers le nouvel état fusionné.
  • Ouvrez Model.edmx et "Update Model from Database".
  • Renommez toutes les propriétés de navigation grillées lors de la fusion.
Frank Shearar
la source
1
Cette critique n'est pas valable pour EF Code First mais s'applique à Model First et Database First.
Alan Macdonald
Je crée moi-même tous les mappages à l'aide de Fluent et prends le contrôle total du mappage. Ceux-ci sont placés dans un fichier .cs séparé.
Steven Ryssaert
5

Il manque quelques autres avantages à EF:

  • Vous pouvez avoir une table d'entité
  • Vous pouvez diviser une table en plusieurs types d'entités
  • Vous pouvez générer les entités à partir de la base de données (c'est-à-dire la base de données comme approche principale)
  • Vous pouvez générer la base de données à partir d'entités (c'est-à-dire du code comme approche principale)
  • Les requêtes LINQ sont converties en requêtes SQL, améliorant ainsi leurs performances.

Les inconvénients (en particulier si vous utilisez la validation):

  • Vous devez créer un attribut [MetadataClass] qui pointe vers une autre classe qui possède les propriétés que vous souhaitez valider avec les attributs de validation appropriés. Toutes les propriétés sont des objecttypes, donc c'est juste là pour lire les métadonnées. Encore beaucoup de code inactif supplémentaire.
  • Utiliser EntityFramework est un concept différent de la façon dont quelque chose comme NHibernate (et la version Java parent également) est conçu pour fonctionner. EntityFramework fonctionne mieux dans un mode attaché où les objets utilisent une connexion en direct à tout moment. NHibernate et les outils ORM similaires fonctionnent mieux en mode détaché où la connexion n'est utilisée que lors du chargement / enregistrement des données.

Ce sont les deux principales plaintes que j'ai. Il y a un certain nombre d'avantages, mais vous pourriez très bien pouvoir obtenir ces mêmes avantages de NHibernate. Si EntityFramework est sur la table, demandez également à l'équipe de vérifier NHibernate et de tirer rapidement sur les avantages / inconvénients de votre projet.

Le problème des classes de métadonnées est un casse-tête, mais heureusement, je n'ai que tant d'entités qui ont besoin de balises de validation.

L'absence d'un véritable mode détaché pour vos objets limite ce que vous pouvez faire dans un environnement Web. Le mode attaché est meilleur pour les applications de bureau, qui sont à l'origine d'un certain nombre d'innovations Microsoft. Le mode détaché est possible , mais très douloureux. Dans ce cas, il est préférable d'utiliser un outil alternatif.

Berin Loritsch
la source
Votre soi-disant code comme approche principale est officiellement appelé code d'abord
Robert Koritnik
1
@Berin, je veux clarifier ce que vous entendez par "mode attaché". Je ne pense pas qu'Entity Framework ait une connexion à la base de données ouverte à tout moment. Je crois que EF fonctionne de manière similaire à NHibernate à cet égard. Est-ce ce que vous voulez dire ou voulez-vous dire autre chose? Avez-vous un lien vers la documentation qui explique ce problème ci-joint?
RationalGeek
1
Par attaché, je veux dire que toutes vos interactions avec les objets doivent avoir lieu dans la using(EFConnection conn = new EFConnection)construction. Si vous essayez de cacher cet objet quelque part pour le conserver en toute sécurité afin de pouvoir effectuer une mise à jour rapide et l'enregistrer à nouveau dans une deuxième using(...)déclaration, vous devrez réfléchir à nouveau. Voir msdn.microsoft.com/en-us/library/bb896271.aspx et msdn.microsoft.com/en-us/library/bb896248.aspx . Utiliser EF 3.5 (que j'ai dû utiliser sur la dernière version) n'est même pas si propre.
Berin Loritsch
D'accord, je comprends ce que tu veux dire maintenant. Je voulais juste m'assurer que les gens ne considéraient pas cela comme signifiant qu'il y avait toujours une connexion à la base de données . Vous devez avoir un contexte d'objet qui maintient l'état des entités "attachées".
RationalGeek
2
Ce n'est pas vrai. EF a une forte notion d'entités détachées. Une entité détachée doit être rattachée à son contexte avant de pouvoir effectuer des opérations liées au contexte contre elle (comme la mettre à jour dans la base de données). De plus, les classes de métadonnées ne sont nécessaires que si EF génère vos entités pour vous. Les POCO, l'OMI, sont une bien meilleure façon d'utiliser l'EF. L'utilisation de POCO simplifie beaucoup de choses, en particulier les tests.
Matt Greer
2

Une chose que Microsoft n'est pas très bon est la compatibilité de comparabilité en amont, surtout en ce qui concerne les nouvelles technologies

Plus précisément, EF1 (.net 3.5) est très différent d'EF4 (.net 4.0) - la même chose pourrait se produire pour la prochaine version.

J'attendrais un moment et verrais comment la technologie évolue.

En attendant, pensez à utiliser nHibernate - ce n'est pas équivalent, mais il est mature et largement utilisé.

Ophir Yoktan
la source
1
  • Simplement ... le modèle de domaine est rarement une réplique du modèle relationnel dans votre base de données. Donc, mapper certaines tables à une classe et les jeter sur le fil est tout simplement de la paresse. Les tables peuvent mapper localement en 1 objet même si la base de données est constituée de 3 tables différentes. Concevez intelligemment la base de données.
  • 2ème ce truc EF ne peut pas générer certaines requêtes et vous devrez quand même les écrire.
  • 3ème Le modèle de domaine ne mappe pas directement sur les services.
  • 5Th capacité de test ... Impossible de créer suffisamment de tests granulaires qui fourniront une régression suffisante contre les modifications de code ... tout est facile à
    casser ...

Je pourrais écrire une diatribe de 10 pages. Mais, si vous écrivez simplement une application à jeter pour la société X .. qui s'en soucie. Mais, si vous développez un produit logiciel ... vous allez devoir être beaucoup plus anal

user104468
la source
Cet article est plutôt difficile à lire (mur de texte). Pourriez - vous l' esprit modifier ing dans une meilleure forme?
moucher
EF ne génère pas d'objets de domaine. Ce sont DAO. Vous devrez utiliser les données de l'objet pour créer votre objet de domaine. De toute façon, vous ne devriez pas renvoyer d'objets de domaine à partir d'un service, alors créez votre DTO plus fin à partir de vos objets de domaine avant de revenir. EF devrait être capable de générer presque tout ce que vous pouvez exprimer dans LINQ. La base de données ne fait pas partie d'un test unitaire, elle fait partie d'un test fonctionnel. Cela dit, il existe des simulateurs de mémoire disponibles pour EF. Sinon, résumez vos requêtes EF dans un référentiel, puis modifiez-les à la place.
Sinaesthetic
Oui, je suis d'accord. Je fais plutôt référence aux modèles établis par Martin Fowler et Carig Lairman. En fin de compte, je ne peux pas utiliser CTE, PARTITION BY ou CROSS APPLY. Je ne peux pas non plus utiliser un IDataReader qui permet de garder une surcharge de mémoire faible. De plus, lorsque j'exécute SQL Trace et que je vois ce que EF envoie sur le fil, j'ai l'impression que je pourrais lancer ;-)
user104468
0

Vérifiez ceci: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Les points principaux sont:

  • Manque de chargement paresseux
  • Manque d'ignorance persistante
  • Le format de fichier utilisé pour enregistrer le modèle d'entité contient à la fois des éléments de visualisation et le modèle d'entité lui-même provoque des problèmes de fusion dans l'environnement d'équipe.

Notez que le lien ci-dessus parle d'EF1.

Ce lien: http://ormeter.net/ montre également que EF n'est pas le meilleur par rapport aux autres ORM en termes de performances et de prise en charge LINQ.

M.Sameer
la source
Gardez à l'esprit que cela a été publié lorsque EF 1 était encore récemment sorti (ou peut-être encore en version bêta). La situation est bien meilleure aujourd'hui avec EF 4, et de nombreuses questions soulevées lors de ce vote de défiance ont été résolues.
RationalGeek
Le dernier point compte toujours et est très significatif.
M.Sameer
1
La première version EF était la 3.5. Il n'y a pas eu quatre versions principales d'EF publiées.
Matt Greer
3
@Matt c'est correct. Mais la version actuelle est appelée EF 4 afin de s'aligner avec le reste du versioning .NET 4.
RationalGeek
1
Que ce soit valide ou non ne devrait pas affecter le résumé du lien. Les votes montreront si c'est valide. :)
Adam Lear