Faut-il utiliser Entity Framework?

31

Nous avons actuellement la pile suivante:

VS 2005
Formulaires Web
SQL Server 2005
IIS 6

Nous prévoyons de passer à ceci:

VS 2010
MVC et formulaires Web
SQL Server 2008
IIS 7

Ma question est la suivante: lorsque nous passons à MVC avec VS 2010, devons-nous utiliser Entity Framework (ou un autre ORM), un micro ORM (comme Massive ) ou simplement du SQL?

Tous les didacticiels que j'ai lus sur VS 2010 sont tous destinés à utiliser Entity Framework pour les transactions de données, mais cela va-t-il durer dans un avenir prévisible (5 ans et plus)?

Si cela est important, les applications de nos clients peuvent compter de 10 à 1 000 utilisateurs actifs.

— guanome
source

Utilisez-vous actuellement Linq-to-SQL?

— Morgan Herlocker

Nous utilisons SQL paramétré

— guanome

4

Évitez d'utiliser SQL directement dans votre développement futur. ORM ou EF sont presque un must. Consacrez quelque temps à avoir une stratégie pour votre couche d'accès aux données. C'est une décision critique et ce n'est pas une tâche insignifiante. Assurez-vous que vous et votre équipe disposez de suffisamment de temps pour l'apprendre. L'introduction de nouvelles technologies de base dans l'équipe doit être gérée. Choisissez l'outil, choisissez le matériel, faites des études, ..., puis évaluez et décidez.

— NoChance

2

Bases de données nouvelles ou existantes? Il y a potentiellement une énorme différence entre la construction d'une nouvelle base de données avec les conventions d'EF à l'esprit et la tentative de moderniser EF sur une base de données existante qui n'a pas été conçue pour les ORM.

— rmac

@rmac C'était pour une nouvelle base de données.

— guanome

45

Je suis récemment passé de l'utilisation de requêtes SQL en ligne à l'utilisation d'EF et voici ce que j'ai trouvé:

Avantages

Beaucoup plus rapide pour construire le DAL (j'adore ne pas écrire les requêtes SQL!)
Beaucoup plus facile à entretenir
Plus besoin de me rappeler d'analyser mes entrées avant de construire une instruction sql en ligne, ce qui signifie moins de chances d'une attaque par injection SQL (bien sûr, cela est toujours possible en fonction de vos requêtes, mais beaucoup moins probable)

Les inconvénients

Impossible de couvrir plusieurs bases de données ... du moins pas facilement
Toutes les entités (tables, vues, etc.) ont besoin d'une clé primaire
Si vous souhaitez mettre à jour une seule colonne dans une table de plus de 100 colonnes requises (pas ma conception de table), vous devez dérouler les 100 colonnes pour effectuer la mise à jour. Ou utilisez une procédure stockée.
J'ai rencontré des problèmes avec certaines valeurs par défaut définies sur SQL Server qui ne sont pas récupérées dans le modèle d'entité après l'ajout d'un nouvel enregistrement. Habituellement, c'est avec des valeurs calculées ou des valeurs qui sont ajoutées dans un déclencheur INSERT
À l'occasion, les requêtes SQL sont mal écrites et sont lentes à exécuter. Si vous avez une requête à exécution lente, exécutez une trace SQL pour voir ce que fait EF. Il est possible que vous puissiez retravailler cette requête en tant que SP ou vue. Cela n'arrive pas si souvent.
J'ai eu quelques problèmes avec la tentative de création d'une association entre des tables qui n'ont pas de clé étrangère définie dans SQL Server. Habituellement, c'est parce que j'essaie de créer une 1:0-1relation où EF veut utiliser un1:0-*

Je ne suis pas un expert EF cependant, j'ai donc probablement raté certaines choses. Ce ne sont que les éléments que je sais que j'ai rencontrés dans le passé lors du passage de SQL en ligne à Entity Framework. Je suis content d'avoir fait le changement, mais il y a eu des moments où j'ai vraiment détesté EF en raison de ses caprices.

— Rachel
source

7

+1 pour une réponse détaillée et organisée. «Toutes les entités (tables, vues, etc.) ont besoin d'une clé primaire» sonne comme une restriction raisonnable plutôt que comme un con.

— NoChance

2

@EmmadKareem C'est une restriction correcte si vous avez le contrôle de la base de données, mais si vous travaillez avec une base de données tierce ou avec des vues, cela peut être un peu ennuyeux

— Rachel

1

Essayez simplement d'utiliser EF dans une application Web N-Tier déconnectée - mise à jour des entités dans une session et des relations MM, hmmmmm quel plaisir!

— Vidar

5

Les entités @EmmadKareem ont vraiment besoin d'une clé primaire à valeur unique - l'utilisation de clés composites est un cauchemar dans EF. C'est une contrainte plutôt qu'une restriction raisonnable.

— Kirk Broadhurst

1

Je dirais que la sécurité est un autre problème. Beaucoup pensent que tout accès à la base de données doit passer par des procédures stockées avec des rôles de base de données associés aux procs pour déterminer quelles connexions peuvent exécuter quels procs stockés. Cela exclut EF / LINQ pour la création de requêtes. J'ai utilisé EF mais j'ai rencontré des clients ( toussant Microsoft) qui avaient ces exigences de sécurité

— Mick

12

Entity Framework est un outil de productivité. Sauf si vous avez une bonne raison de ne pas le faire (par exemple, vous êtes sur SQL 2000 ou n'avez pas le temps de vous lancer dans la technologie), utilisez les meilleurs outils à votre disposition.

Cela étant dit, je trouve que le concept d'entités se traduit très bien dans le modèle du modèle MVC. Tout en ayant une relation 1: 1 avec les modèles et les tables est une mauvaise pratique, penser en termes d'entités a tendance à produire des conceptions propres, un code facile à lire (en particulier avec LINQ).

Entity Framework est activement pris en charge par Microsoft. Personne n'a une boule de cristal magique pour dire "le soutien durera X ans". Je ne vois aucune raison de croire que l'entité mourra au cours des 5 prochaines années.

— P.Brian.Mackey
source

3

LinqToSql est mort assez rapidement, il n'y a donc vraiment aucune raison de croire d'une manière ou d'une autre si Entity Framework survivra. Il vaut la peine de prendre en considération la nouvelle poussée de MS vers Metro, dans la mesure où ils envisagent de réviser bon nombre de leurs offres.

— ocodo

3

Slomojo, vous avez peut-être une définition différente du reste du monde du mot «Dead». Parce que LinqToSql n'est tout simplement plus développé activement. Vous pourrez toujours l'utiliser dans 10 à 20 ans.

— Boris Yankov

4

Une autre solution potentielle consiste à utiliser une autre bibliothèque Entity Framework qui n'est pas celle fournie avec VS. Il y en a quelques-unes sur le Web.

Le concept de framework Entity / 3 couches existe depuis un certain temps et a fonctionné avec plusieurs bibliothèques personnalisées, comme de nombreux autres développeurs, avant que Microsoft ne publie son propre framework "officiel".

Avantages

Bénéficiez des avantages du framework Entity (DAL), sans être bloqué par les changements constants de bibliothèques / framework de Microsoft.

Ajouter des fonctionnalités à une bibliothèque qui ne sont peut-être pas disponibles pour la bibliothèque officielle existante, comme utiliser plusieurs marques de base de données.

Les inconvénients

Doit prendre en charge la bibliothèque ou les outils. Il est très courant d'avoir un outil de génération de code d'entité pour générer les entités.

— Umlcat
source

Je trouve cette réponse très déroutante. Il n'y a qu'un seul Entity Framework (avec des majuscules) qui est celui que Microsoft produit. Voulez-vous dire "utiliser un autre mappeur relationnel d'objet"? Entity Framework n'est pas un terme générique - c'est le nom de l'ORM de Microsoft.

— NickG

Bien qu'il existe un "Microsoft Entity Framework", le concept "Entity Framework" existe depuis plusieurs années.

— umlcat

3

Vous devez prendre une décision architecturale en fonction du problème et de la solution existante. Comme pour toute technologie, il y a des avantages et des inconvénients.

Personnellement, j'utiliserais normalement le framework d'entité pour de nouveaux développements mais ne réécrirais pas le code existant. Vous obtenez alors la vitesse de développement futur, mais vous n'avez pas à investir beaucoup de temps pour convertir le code. L'inconvénient de cette approche est qu'elle réduit la cohérence.

— Tom Squires
source

3

+1 pour avoir recommandé de ne pas réécrire le code de travail.

— NoChance

2

Dans votre situation, j'utiliserais certainement Entity Framework, j'ai trouvé que cela fonctionne bien avec MVC.
Voici quelques vraies raisons et indications.

Linq est un plaisir à utiliser, et l'exécution retardée est également extrêmement utile.
Vous pouvez générer vos modèles (cependant, lors de l'utilisation avec mvc, je vous recommande d'utiliser des modèles de vue conjointement avec les modèles de données, cela rend la validation et la liaison de modèle beaucoup plus faciles, si vous adoptez cette approche, utilisez automapper pour mapper les modifications sur votre modèle de données).

Il y a cependant un certain nombre de choses que vous devrez apprendre à utiliser un ORM.

Ce que le contexte fait pour vous (suivi des entités)
Qu'un contexte devrait être utilisé comme unité de travail
N'oubliez pas de penser à la concurrence, EF peut vous dire quand votre objet est obsolète, mais cela peut être difficile si vous souhaitez gérer correctement la concurrence entre les demandes (car vous devez garder un horodatage ou quelque chose).

Choses à considérer

Les déclencheurs et les ORM ne fonctionnent pas ensemble, utilisez plutôt les événements ORM.
Assurez-vous que toutes vos tables ont des clés promary.

Je recommanderais également fortement l'approche du code en premier, même si vous avez une base de données existante.

Les conventions signifient que vous n'avez pas besoin de régénérer les mappages ou les classes lorsque vous modifiez la base de données.
Il est plus important de placer la validation et d'autres logiques dans les modèles.
Vous pouvez utiliser le générateur de code pour les créer si vous avez une énorme base de données existante.

— Daniel Little
source