Quand NE PAS utiliser l'Entity Framework

Question

J'ai joué avec l'EF pour voir ce qu'il peut gérer. De plus, de nombreux articles et messages expliquent les différents scénarios dans lesquels l'EF peut être utilisé, mais il manque parfois le côté "contre". Ma question est donc la suivante, Dans quels types de scénarios dois-je éviter d'utiliser Entity Framework ? ?

Si vous avez une certaine expérience dans ce domaine, dites-moi quels sont les scénarios qui ne fonctionnent pas bien avec le FE. Parlez-moi des inconvénients que vous avez rencontrés et qui vous ont fait regretter d'avoir choisi une autre technologie.

Answer 1

En Vote de défiance énumère plusieurs faux pas et/ou des fonctionnalités manquantes aux yeux de ceux qui pensent savoir quelles fonctionnalités, et leurs implémentations, sont appropriées pour les frameworks ORM/Datamapper.

Si aucun de ces problèmes ne vous préoccupe, je ne vois pas pourquoi vous ne l'utiliseriez pas. Je n'ai pas encore entendu dire qu'il s'agissait d'un système bogué qui explosait à droite et à gauche. Toutes les mises en garde à son encontre sont d'ordre philosophique. Il se trouve que je suis d'accord avec le vote de défiance, mais cela ne veut pas dire que vous devriez. Si vous aimez la façon dont EF fonctionne, alors allez-y. Dans le même temps, je vous conseille de lire au moins le vote de défiance et d'essayer d'avoir une compréhension rudimentaire de chacun des problèmes afin de prendre une décision éclairée.

En dehors de ce problème et au cœur de votre question - Vous devez garder un œil sur le Sql qui est généré afin que vous puissiez faire des ajustements avant qu'un problème de performance n'entre en production. Même si vous utilisez des procs sur le backend, je rechercherais toujours les scénarios où vous pouvez frapper la base de données trop souvent et retravailler vos mappings ou scénarios de récupération en conséquence.

Answer 2

Un problème potentiellement important : Entity Framework 1.0 ne prend pas en charge l'ignorance de la persistance. Cela signifie que votre couche métier est dépendante de votre couche d'accès aux données.

Si l'ensemble de votre application est hébergé dans le même processus (comme un site web sur IIS), cela ne pose aucun problème.

Si, toutefois, vous avez besoin d'envoyer vos entités à distance (vers un client Silverlight ou Windows Mobile, par exemple), vos entités ne pourront pas facilement être sérialisées à travers le fil. Vous devrez créer des classes de transfert de données distinctes pour envoyer vos entités sur le fil, ainsi qu'une logique supplémentaire pour transporter les données entre vos classes d'entités et les DTO.

Edita: l'orthographe.

Answer 3

Je n'en suis qu'au stade de l'expérimentation, et même si je m'inquiétais de l'absence d'agnosticisme intégré en matière de persistance, j'étais sûr qu'il y aurait une solution de rechange.

En fait, il ne s'agit même pas d'une solution de rechange dans une architecture n-tiers.

WCF + EF

Si j'ai lu le article correctement, alors je ne vois aucun problème à sérialiser les entités à travers le fil (en utilisant WCF) et aussi l'ignorance de la persistance n'est pas un problème.

En effet, j'utiliserais PI principalement pour les tests unitaires.

Tests unitaires es possible ! (je pense)

Dans ce système, nous pourrions simplement utiliser un service fictif (en enveloppant l'appel au service dans une AUTRE classe basée sur une interface qui pourrait être produite à partir d'une usine, par exemple). Cela permettrait de tester NOTRE code de présentation (il n'est pas nécessaire de tester l'unité EF/DAL - c'est le travail de Microsoft !) Bien sûr, des tests d'intégration seraient toujours nécessaires pour obtenir une confiance totale.

Si vous vouliez écrire dans une base de données distincte, cela se ferait dans la couche DAL, facilement réalisable via le fichier de configuration.

Ce que j'en pense

Mon avis : faites-vous votre propre opinion sur l'EF et ne vous laissez pas décourager par tous les discours catastrophistes qui circulent à son sujet. Je pense qu'il sera là pendant un certain temps et que MS corrigera ses défauts d'ici un an ou deux. D'après Dan Simmons, PI va certainement arriver.

EDIT : Je viens de réaliser que j'ai sauté le pas et, comme un bon politicien, je n'ai pas vraiment répondu à la question posée. Oups. Mais je vais laisser ce message au cas où quelqu'un d'autre le trouverait utile.

Answer 4

Tous les modèles de données ne sont pas forcément adaptés aux entités de l'application. Si le mappage n'est pas relativement simple, j'éviterais l'Entity Framework. Vous vous retrouverez à faire des exercices d'équilibre pour le faire fonctionner sans en tirer aucun avantage.

Anders Hejlsberg a fait des commentaires intéressants sur le mappage objet/relationnel. ici .

Answer 5

Comme EF ne supporte pas le POCO, il peut être difficile d'écrire de bons tests unitaires contre celui-ci. C'était l'une des critiques formulées à l'encontre de EF dans l'étude de l Vote de défiance .

Si vous voulez écrire de bons tests, EF va soulever des obstacles. Vous pouvez les contourner mais ce n'est pas trivial.