Pourquoi ne pas utiliser les classes générées par EF dans les grands projets?

Question

Je vais utiliser Entity Framework 4 dans une sorte de gros projet.

Et je sais que de nombreux programmeurs professionnels conseillent de dépendre de mes classes d'affaires au lieu des classes EF Model.

En fait, il y a du son à l'intérieur de mon cerveau, dites-moi "Ne comptez pas sur les classes générées! ... Il suffit de se salir la main pour ne pas laisser quelqu'un d'autre faire ça pour vous !!" Mais en réalité, je ne sais pas où est le problème d'utiliser ces classes générées dans un si grand "Enterprise" des projets.

Alors s'il vous plaît faites-moi comprendre pourquoi ???

Answer 1

Il n'y a absolument rien de mal à utiliser les classes générées par EF. C'est ce qu'ils sont là pour ça. Mais si vous utilisez mal la technologie, vous avez beaucoup de problèmes. Par exemple, beaucoup de débutants vont essayer d'utiliser ces classes générées par EF pour tout. Ils prendront les cours, les guideront à travers une frontière AppDomain avec WCF ou Remoting, et peut-être qu'ils se lieront à eux sur leur front end. Cela pourrait fonctionner pour une application CRUD rapide et sale, mais ça ne va pas voler pour n'importe quoi avec n'importe quelle taille réelle.

Pourquoi pas? Parce que les classes générées par EF sont modélisées dans le "domaine" de données de votre application, pas dans la présentation "domaine". Ce qu'un utilisateur peut vouloir interagir avec n'est souvent pas un objet 1: 1 avec une table dans votre base de données. Par exemple, un utilisateur peut avoir une grille de "Produits". À l'intérieur de cette grille serait le total des dollars vendus du produit, ainsi que certaines données indicatives sur le produit. Bien que les données indicatives (Nom, Taille, etc.) proviennent probablement de la table Product et donc de la classe Product générée par EF, les données agrégées (total des dollars vendus) représentent une valeur agrégée. En général, nous utilisons les classes générées par EF dans notre service, puis nous utilisons le service pour traduire les classes EF en ViewModels, que nous lions ensuite sur nos frontaux en utilisant WPF (ou quelle que soit votre technologie favorite) . Cela nous donne la séparation des préoccupations que nous recherchons.

Answer 2

En plus de la bonne réponse de Dave, je voudrais mentionner un autre inconvénient important de l'utilisation des classes générées: elles sont dérivées d'une classe de base commune (EntityObject). Si vous disposez d'un modèle de domaine existant avec sa propre hiérarchie d'héritage, cela peut poser problème car l'héritage multiple n'est pas pris en charge dans .NET.

Answer 3

Si votre projet est volumineux, je vous recommande de suivre Domain Driven Development. Chaque classe de domaine comprend un certain nombre de composants: propriétés d'entité EF, injection de propriétés pour les comportements (mise en forme des données, analyse, conversion, copie, validation, configuration).

Si vous suivez le principe de la responsabilité unique, chaque classe ne devrait avoir qu'une seule responsabilité. Les classes de modèle EF doivent être destinées à stocker des données et à communiquer avec l'infrastructure EF pour générer le code SQL d'exécution. Les autres classes se chargeront du formatage, de la conversion, de la validation et du transfert.

Lorsque le nombre de types augmente, vous devez les centraliser ou les organiser en utilisant le modèle de façade. Ces façades sont des types spécifiques au domaine. Donc, si vous commencez à générer des modèles EF, puis créez les types de support (formateurs, validateurs, ...), et enfin créez des types de domaines, vous n'aurez pas plus de possibilités de collaboration et de distribution que vous auriez pu en inversant.Construisez d'abord vos types de domaine, construisez des modèles et des tests unitaires, puis partagez-les avec vos pairs pour leur permettre de connecter les fonctions de l'objet domaine aux modèles EF. C'est ainsi que vous pouvez faire du développement piloté par le domaine.

Answer 4

Il faut être très prudent lors de l'exposition des classes générées EF jusqu'au Javascript.

Tout d'abord, vous pouvez exposerons trop de champs que vous avez besoin. Cela augmentera la charge utile et permettra aux attaquants de deviner facilement le schéma de votre base de données. Deuxièmement, si vous laissez également le classeur modèle MVC désérialiser les données HTTP (via un corps de requête, une URL ou n'importe quel moyen) dans des modèles EF, puis les enregistrer directement dans la base de données, vous courez un grand risque. N'importe qui devrait être en mesure de tempérer les requêtes HTTP pour vous envoyer un objet JSON qui remplacerait les champs auxquels vous ne vous attendiez pas. Réfléchissons achats objet panier:

{cartItems: [{itemId:1, quantity:100, product:{ productId:23, price:0 }}]} 

Si je pouvais passer dans un product avec le prix 0 et productId valide, EF remplace le prix du produit spécifié dans votre base de données.