Utilisation d'entités Entity Framework en tant qu'objets métier?

.net architecture entity-framework

Question

J'utilise le mappeur O / R Entity Framework de Microsoft et des classes d'entités (les classes générées mappées sur des objets de base de données) en tant qu'objets métier. Est-ce correct? S'il vous plaît indiquer vos inconvénients ou les avantages. Que faire en cas de communication WCF entre la couche de gestion et la présentation, comment envoyer ces objets en tant que membres de données?

Réponse acceptée

J'utilise EF de cette manière et une fonctionnalité intéressante est que les entités générées sont des classes partielles, ce qui leur permet d'être étendues d'une manière assez protégée des problèmes de régénération.

Jetez également un coup d'œil à ce lien sur MSDN qui décrit certains scénarios d'utilisation courants avec EF en ce qui concerne Business Logic.


Réponse populaire

Tout d'abord, avec 11 000 questions au moment de la rédaction de cet article, je suis un peu surpris par le manque de réponses et, avec tout le respect que je vous dois, par la qualité des réponses, compte tenu d'une question assez simple.

Donc, maintenant que je me suis un peu laissé aller, j'aimerais aborder cette (ces) question (s) car je pense que cela s'applique encore plus aujourd'hui avec la récente publication de Entity Framework Code-First.

"Utilisation d'entités Entity Framework en tant qu'objets métier?"

Quelques précisions avant de commencer:

  • Lorsque vous parlez d '"objets métier", j'ai l'impression que ces objets contiennent des règles ou une logique allant de, par exemple, une simple validation (champs obligatoires) à une logique plus complexe (traitement d'impôts lors d'un paiement, par exemple).

  • Je ne pense pas pouvoir répondre à votre question suivante concernant la WCF. La raison en est tout simplement parce que je vais répondre objectivement à vos questions sur EF en tant qu’objets commerciaux, ce qui me contraindrait alors subjectivement à adopter une position contradictoire par rapport à ma tentative de réponse réelle et objective à la première question.

Cela dit, sur votre EF en tant qu’objet d’objets commerciaux ...

"J'utilise le mappeur O / R Entity Framework de Microsoft et j'utilise des classes d'entités (les classes générées mappées sur des objets de base de données) en tant qu'objets métier. Est-ce correct?"

Désolé, il n'y a tout simplement pas de bonne ou de mauvaise réponse ici. Cela dépend de votre objectif et de ce que vous estimez être la conception la plus raisonnable, tout en comprenant parfaitement les avantages et les inconvénients de le faire.

 «Veuillez indiquer vos inconvénients ou vos avantages »

Je suis content que vous ayez demandé! Je serai heureux de répondre et mon espoir est que, compte tenu du pour et du contre, vous êtes en mesure de prendre une décision éclairée quant à savoir si vous croyez ou non qu'utiliser EF pour vos objets métier est «OK». En général, je parlerais des avantages et des inconvénients, ce qui faciliterait la tâche de «digérer». Cependant, je ne pense pas que ce soit approprié ici, car je pense que nous ferions une injustice à un sujet aussi intéressant. qui est également proche et cher à mon coeur.

Tout d’abord, permettez-moi de parler techniquement un instant… Vous pouvez utiliser des objets EF comme objets de travail, rien ne vous empêche techniquement de le faire. En fait, EF Code-First (CF) vous simplifie la tâche en vous permettant de créer des POCO et en vous donnant la possibilité d'appliquer des annotations de données pour une validation simple et d'implémenter IValidatableObject pour une validation plus complexe. Assez cool, hein?

C'est là que réside le coeur de la discussion.

EF, ou n’importe quel ORM, est conçu pour prendre en charge la gestion des données. Les données sont sa principale responsabilité. Par conséquent, les objets que vous créez sont centrés sur les données. Donc, si vous essayez de concevoir également vos objets en fonction de leur comportement, vous avez un petit problème à résoudre. En bref, cette énigme est appelée inadéquation impédance. Imaginez ceci; vous avez deux cas d'utilisation requis dans votre application:

  1. Un écran pour éditer un utilisateur
  2. Un contrôle pour afficher un sous-ensemble en lecture seule des informations utilisateur

Si vous utilisez EF (n'importe quelle saveur), ou n'importe quel ORM, vous pouvez utiliser le même objet "Utilisateur" pour gérer la possibilité de sauvegarder un utilisateur et d'extraire un utilisateur pour extraire le sous-ensemble de champs en lecture seule. . Vous le faites probablement pour l'une des raisons suivantes:

  1. Comme beaucoup de développeurs, nous avons cette graine plantée dans nos cerveaux pendant l’éducation - la «consolidation de code» est d’une importance capitale ou peut-être mieux connue sous le nom de DRY - Ne vous répétez pas, et vous pouvez donc regarder la duplication de code, telle que en tant que propriétés, dans un contexte négatif.
  2. Les ORM, tels que EF 4.1, ont des limitations techniques (et des solutions de rechange rigoureuses) telles que le mappage de plusieurs objets / objets POCO dans la même table de base de données, ce qui vous oblige à le faire indépendamment de vos convictions.
  3. C'est un moyen rapide et facile de mettre en marche une application.
  4. C’est la bonne chose à faire.

Cela présente des avantages et des inconvénients et vous pouvez considérer que cela est positif ou négatif, selon votre opinion.

Je suppose que si vous croyez en la normalisation du code par rapport au comportement, vous avez grandement réussi. Vous avez été en mesure de limiter la quantité de code, voire de gagner du temps, en écrivant un seul objet pour gérer vos données et vos cas d'utilisation commerciaux pour cette entité.

Et je suppose que si vous croyez en la normalisation du comportement par rapport au code, vous échouerez lamentablement. En économisant sur le code, vous avez sacrifié la conception d'objets en raison de leurs responsabilités, ce qui rend potentiellement difficile la gestion de celui-ci et, par conséquent, augmente les coûts de maintenance.

Indépendamment de votre opinion, nous pouvons probablement tous convenir que cet objet métier a assumé de multiples responsabilités et que son comportement (et non ses données!) Est au mieux secondaire. Sa principale responsabilité est la gestion des données et ses responsabilités secondaires sont le traitement des règles métier, simples et complexes, impliquées dans l'édition d'un utilisateur et l'affichage d'informations en lecture seule. Dans la conception orientée objet (OOD), si la conception d'un objet est caractérisée par son identité et son comportement, cet objet pourrait être un individu confus, car il n'adhère pas à la définition même de OOD.

Quelque chose à considérer d’un point de vue technique, chaque fois que vous demandez à l’objet utilisateur que vous héritez d’une surcharge importante. Cela peut inclure des éléments tels que toutes les propriétés et les règles métier lors de l'affichage d'un sous-ensemble d'informations en lecture seule.

Alors, qu'est-ce que tout cela a à voir avec le fait que je devrais ou non utiliser EF pour représenter mes objets métier?

Bien… Bien que cela soit techniquement possible, il existe différentes philosophies (des bonnes, des mauvaises) selon que vous devez ou non utiliser EF, ou un autre ORM, pour représenter vos objets métier. J'ai donné un résumé au cœur de ces philosophies ci-dessus, mais elles sont documentées de manière beaucoup plus détaillée par des individus tels que Rocky Lhotka et Martin Fowler.

La direction que vous prendrez dépendra probablement de l’application et, d’un point de vue philosophique, de votre degré d’idéalisme ou de pragmatisme. Cela dit, je ne veux pas dire que le fait d'être idéaliste ou pragmatique est lié à l'utilisation de EF pour des objets métier ou non - cela aura simplement un impact sur votre vision de ce sujet.

À la date de rédaction de ce document, Microsoft indique que les EF sont conçus pour gérer la logique d’entreprise et, qu’ils soient bons ou faux, ils semblent aller davantage dans cette direction. EF est en constante évolution et certaines limitations techniques sont levées, de sorte que EF peut éventuellement être utilisé pour satisfaire le meilleur des deux mondes. En d'autres termes, vous pourrez éventuellement avoir votre gâteau et le manger aussi.

J'espère que cela t'aides.

Je suis prêt à répondre à une question sur le fait de savoir si la persistance de l'ignorance avec un ORM est ridicule compte tenu de son objectif fondamental: la gestion des données. :-) Désolé, je n'ai pas pu résister!



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow