Utiliser les entités d'Entity Framework comme objets d'entreprise ?

Question

J'utilise le mappeur O/R Entity Framework de Microsoft et j'utilise les classes d'entités (classes générées qui sont mappées aux objets de la base de données) comme objets d'entreprise. Est-ce que cela est acceptable ? Veuillez indiquer vos avantages et inconvénients. Que faire dans le cas d'une communication WCF entre la couche métier et la présentation, comment envoyer ces objets comme membres de données ?

Answer 1

Tout d'abord, avec 11k question de point de vue au moment d'écrire ces lignes, je suis un peu surpris par le manque de réponses et avec tout le respect, la qualité de la réponse, compte tenu d'une question assez simple.

Donc, maintenant que j'ai ventilé un peu, j'aimerais répondre à cette question(s) parce que je pense que c'est encore plus vrai aujourd'hui avec la sortie récente de l'Entity Framework Code First.

"À l'aide de Entity Framework entités business objects?"

Un couple de points de clarification avant que j'ai commencé:

• Quand vous dites "business objects", j'ai l'impression que ces objets vous référer à contenir des règles ou de la logique, allant, par exemple, une simple validation (I. e les champs requis) à une logique plus complexe (I. e. le traitement de l'impôt sur la caisse).

• Je ne pense pas que je puisse répondre à votre question de suivi concernant la WCF. La raison pour cela est tout simplement parce que je vais objectivement répondre à vos questions sur EF comme business objects, qui serait alors subjectivement me forcer à prendre une position avèrent contradictoires de ma tentative de réellement et objectivement répondre à ladite première question.

Cela dit, sur votre EF comme business objects questions...

"Je suis en utilisant Entity Framework O/R mappeur à partir de Microsoft et à l'aide de entity classes (classes générées qui sont mappés à DB objets) comme une entreprise objets. Est-ce OK?"

Désolé, il n'y a pas de bonne ou de mauvaise réponse ici. Cela dépend de ce que votre objectif est et ce qu'on en conclure, la plus raisonnable de conception tout en comprendre pleinement les avantages et les inconvénients de le faire.

"Veuillez indiquer votre cons ou les pros"

Je suis content que vous avez demandé! Je serai heureux de répondre et mon espoir ici est que, étant donné les avantages et les inconvénients que vous êtes en mesure de prendre une décision éclairée quant à savoir si ou non vous croyez à l'aide de EF pour votre business objects est "OK". Généralement, je préfère casser les avantages et les inconvénients de le rendre facile à "digérer", cependant, je ne pense pas que ce soit approprié ici, car je pense que nous aimerions faire une injustice à un tel sujet très intéressant qui est aussi proche et cher à mon cœur.

Tout d'abord, permettez-moi de parler techniquement pour un moment... Vous êtes en mesure d'utiliser EF objets en fonction de vos objets, il n'en est rien, techniquement, vous empêchant de le faire. Comme une question de fait, EF Code-Première (CF) rend incroyablement facile en vous permettant de créer Poco et vous donnant la possibilité d'appliquer des données d'annotations pour une simple validation ainsi que la mise en œuvre de Ivalidatableobjet pour une validation plus complexe. Plutôt cool, hein?

C'est là que réside le cœur de la discussion.

EF, ou tout ORM, est conçu pour soutenir la gestion des données. Sa responsabilité principale est de données et, par conséquent, les objets que vous créez sont centré sur les données. Donc, si vous essayez aussi de la conception de vos objets par le comportement, alors vous avez un peu d'une impasse sur la main. En un mot, cette énigme est appelé d'adaptation d'impédance. Cette image, vous avez deux cas d'utilisation dans votre application:

1. Un écran pour modifier un utilisateur
2. Un contrôle de l'affichage en lecture seule sous-ensemble des informations de l'utilisateur

Si l'utilisation de EF (toute la saveur), ou tout ORM pour cette question, vous pourriez attirés par l'aide de la même "Utilisateur" objet pour gérer la possibilité d'enregistrer un utilisateur, ainsi que de l'extraction de l'utilisateur de tirer le sous-ensemble de champs en lecture seule. Vous avez probablement le faire pour l'un des plusieurs raisons:

1. Comme beaucoup de développeurs, nous avons cette graine plantée dans notre cerveau au cours de l'éducation "la consolidation de code" est de la plus haute importance ou peut-être mieux connu comme SEC – Ne pas se Répéter, et, par conséquent, vous pouvez regarder la duplication de code, comme les propriétés, dans un contexte négatif.
2. Orm, tel que EF 4.1, ont des limitations techniques (et hackish de rechange), comme l'association de plusieurs POCOs/objets à la même table de base de données ce qui vous forcera à vous, indépendamment de vos croyances.
3. C'est un moyen rapide et facile pour obtenir une application et l'exécution de
4. Il "se sent" comme la bonne chose à faire

Il y a des avantages et des inconvénients à le faire et vous pourriez regarder, il s'agit soit d'une manière positive ou négative en fonction de votre opinion.

Je suppose que si vous croyez en la normalisation de code sur le comportement que vous avez réussi grandement. Vous avez été en mesure de limiter la quantité de code, potentiellement économiser du temps, par écrit, un seul objet à traiter vos données et les cas d'utilisation opérationnelle de l'entité en question.

Et je suppose que si vous croyez en la normalisation de comportement sur le code que vous avez lamentablement échoué. En économisant sur le code que vous avez sacrifié la conception des objets par leurs responsabilités, ce qui pourrait le rendre difficile à gérer et donc une augmentation du coût d'entretien.

Quelle que soit votre opinion, nous pouvons probablement tous d'accord que c'objet de l'entreprise a pris de multiples responsabilités et le comportement (pas de données!) de l'objet est secondaire au mieux. Sa responsabilité principale est la gestion de données et de son secondaire, les responsabilités sont la transformation, les règles métier, à la fois simple et complexe, la modification d'un utilisateur et l'affichage en lecture seule information de l'utilisateur. Dans une conception orientée objet (OOD), si la conception d'un objet est caractérisé par son identité et de son comportement, que cet objet pourrait être confondu l'individu que n'adhèrent pas à la définition même de l'INONDATION.

Quelque chose à considérer d'un point de vue technique, toutes les fois que vous demandez à l'utilisateur de l'objet que vous héritez d'une quantité importante de frais généraux. Cela peut inclure des choses comme l'ensemble des propriétés et des règles d'affaires lors de l'affichage d'un sous-ensemble des informations en lecture seule.

Alors, quel est le sens de tout ce que avez à faire avec si ou pas, je devrais utiliser EF pour représenter mon entreprise objets?

Bien... Alors que c'est techniquement possible, il y a des théories différentes (des bons, des mauvais) sur si oui ou non vous devez utiliser EF, ou tout ORM, pour représenter votre entreprise les objets. J'ai donné un résumé destiné au cœur de ces philosophies ci-dessus, mais ils sont documentés dans beaucoup plus de détails par des personnes telles que Rocky Lhotka et Martin Fowler.

La direction que vous prendrez dépendra très probablement sur l'application et à partir d'un point de vue philosophique, peut dépendre de la façon dont beaucoup d'un idéaliste ou pragmatiste vous êtes. Cela dit, je ne suis pas ce qui implique qu'un être idéaliste, ou pragmatiste corrélation soit à l'aide de EF pour business objects ou pas – il suffit de l'impact de votre prendre sur cette.

De cette écriture, des indications par Microsoft sont que les EF sont construites pour répondre à la logique d'entreprise et, à tort ou à raison, ils semblent se déplaçant plus dans la bonne direction. EF est en constante évolution et certaines limitations techniques sont en train de lever tel que EF peut éventuellement être utilisée pour satisfaire le meilleur des deux mondes. En d'autres termes, par la suite vous pouvez être en mesure d'avoir votre gâteau et le manger aussi.

Espérons que cette aide.

Pour répondre à une question à savoir si ou de ne pas l'ignorance de la persistance avec un ORM est ridicule compte tenu de l'objectif derrière cela est de gérer les données. :-) Désolé, je ne pouvais pas résister!

Answer 2

J'utilise EF de cette façon et une caractéristique intéressante est que les entités générées sont des classes partielles, ce qui permet de les étendre d'une manière qui est 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 quelques scénarios d'utilisation courante de EF en ce qui concerne la logique d'entreprise.

Answer 3

Le cadre Entity a été conçu pour que les objets d'entité soient utilisés en tant qu'objets métier, mais vous devez garder à l'esprit que les objets métier seront liés à la technologie O/R ainsi qu'au modèle GED. Dans EF 1.0, il n'y avait pas de support pour les éléments suivants _[persistance-ignorance](http://blogs.msdn.com/dsimmons/pages/ef-faq-entity-classes.aspx#_Does_Entity_Framework "Does Entity Framework have support for "Persistence Ignorance"? What is Persistence Ignorance?")_ mais la prise en charge a été ajoutée dans la version 4.0. Vous pouvez implémenter interfaces si vous ne voulez pas utiliser l'une de leurs classes de base.

À partir de .NET 3.5 SP1, ils devraient également être utilisables comme paramètres et types de retour dans les méthodes de service WCF sans code supplémentaire.

Answer 4

D'après mon expérience, nous avons utilisé les objets EF dans la couche métier de notre application, mais lorsque nous ferons la transition vers la couche de présentation via notre couche de service WCF, nous créerons des objets de vue à partir des objets EF.

Dans notre cas, seule la vue est transmise à la couche de présentation. Nous faisons cela pour contrôler la façon dont les données sont présentées et appliquer une validation défensive pour les données provenant de la couche de présentation.

Dans le cas de l'ueing des objets EF dans la transaction WCF, vous perdrez le contexte d'objet auquel l'objet EF était associé. Il y a quelques efforts dans CodePlex qui essayent d'aider avec ceci mais je n'ai pas suivi leurs efforts.

Answer 5

Deux limitations dont il faut être conscient et que j'ai rencontrées sont les suivantes :

1. Les objets hérités ne peuvent pas avoir de propriétés de navigation - c'est-à-dire que si vous avez une classe "personne", puis un "client" et un "fournisseur", ces clients et fournisseurs ne peuvent pas avoir de propriétés de navigation.

2. Les méthodes et les champs calculés (tout ce qui se trouve dans les classes partielles) ne sont pas transmis par les services de données ADO.Net - si vous utilisez également les services de données ADO.Net, tout ce sur quoi vous développez les objets Entity Framework dans les classes partielles ne sera pas transmis par les services de données ADO.Net.

Il ne s'agit généralement pas d'éléments rédhibitoires (pour les propriétés de navigation, nous n'utilisons pas l'héritage dans le cadre des entités, pour l'instant), mais ils peuvent vous intéresser. Je garde l'espoir qu'une prochaine version activera ces deux éléments.