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

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?

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.

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.

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.

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é.

• 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

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.