Confusion sur l'endroit où placer la logique métier lors de l'utilisation de la structure Entity

Question

J'ai juste commencé à travailler avec Entity framework et je suis confus au sujet de la façon dont les classes normalement dans la couche de gestion compatibles avec les entités qui sont créées par l'Entity Framework.

Lorsque vous travaillez avec des classiques ADO.NET j'aurais une classe appelée à la Clientèle, par exemple, et une autre classe appelée DALCustomer pour gérer la base de données d'interaction, dans cette structure, j'aurais mis le code pour faire des calculs, de filtrage et de delcare une instance de la DAL au sein de la Clientèle pour la sauvegarde, la mise à jour et la suppression de la classe de la Clientèle.

Avec Entity Framework, si vous avez une table de la Clientèle, Entity framework crée une entité appelée à la Clientèle et c'est là où ma confusion commence, cette entité éliminer le besoin pour un Client dans la couche de gestion? Donc, en substance, tous les champs et les méthodes qui vont normalement dans la couche d'aller dans l'entité générée par l'Entity Framework? Ou de classe existent encore dans la couche de gestion appelé CustomerBL par exemple, qui contient encore des champs et des méthodes nécessaires à la réalisation de la logique de gestion requis pour les calculs, le filtrage et a toujours besoin d'une instance de l'EF DAL déclaré pour gérer l'accès aux données?

Si il doit y avoir une analyse de classe, dans ce cas CustomerBL, une autre question, saute à l'esprit, si les champs sont créés dans l'entité customer être recréé dans CustomerBL ou si une instance de l'entité Customer être déclarée dans CustomerBL donc, il n'y aurait pas besoin d'avoir les champs déclarés dans 2 endroits?

Answer 1

Entity framework, par opposition à linq-to-sql par exemple, a été conçu avec la séparation entre le modèle de données et le modèle conceptuel à l'esprit. Il prend en charge l'héritage, le fractionnement d'entité, table de fractionnement, des types complexes, et transparente plusieurs-à-plusieurs associations (sans jonction de la classe), le tout permettant de mouler le modèle de domaine à ses besoins sans être contraints de trop par la banque de données du modèle.

Le code-première approche permet de travailler avec des POCOs dans lequel les propriétés sélectionnées peuvent être mappées à la banque de données des colonnes. Le modèle de la première et de la Base de données tout d'abord, générer des classes partielles, ce qui permet d'étendre le code généré. Travaillant avec les classes en grande partie a le regard et la sensation de travailler avec POCOs. Encore plus depuis la version 5, DbContext devient la valeur par défaut de l'API, de sorte que les classes générées n'ont plus farcies avec de la persistance du code de l' ObjectContext API.

Bien sûr, cette séparation entre le modèle conceptuel et le modèle de magasin ne peut réussir que dans une certaine mesure. Certaines choses fonctionnent à l'encontre de cet objectif de l'ignorance de la persistance. Par exemple, si le chargement paresseux est souhaitable, il est nécessaire de déclarer les propriétés de navigation en tant que virtual, donc EF peut les remplacer dans les types de proxy. Et il est très pratique pour avoir des primitives propriétés de clés étrangères (par exemple, ParentId) accompagnant le "réel" des associations (un Parent de référence). Les puristes considèrent que cela est une violation de domain-driven design.

Un autre élément important de la violation de l'ignorance de la persistance est le grand nombre de différences entre linq-to-objets et linq-to-entités. Vous ne pouvez pas ignorer le fait que vous êtes linq-ing contre un tout autre univers que les objets en mémoire. Ceci est appelé couplage ou de l'abstraction qui fuit.

Mais alors... en général, je suis heureux avec l'aide d'généré EF classes ou POCOs à partir d'un code-premier modèle de classes du domaine. Jusqu'à présent, je n'ai jamais vu un revêtement à la transition à partir d'une banque de données à l'autre, si il arrive à tous. L'ignorance de la persistance d'une fiction. Particularités de la DAL de toujours laisser une empreinte dans le domaine. Seulement quand vous avez le code pour les différentes banques de données/modèles ou alors des magasins/des modèles sont attendus pour changer relativement souvent, il paie pour réduire cette empreinte, autant que possible, ou abrégé de l'éloigner complètement.

Un autre facteur qui peut favoriser EF classes que les classes du domaine, c'est que de nombreuses applications d'aujourd'hui ont plusieurs niveaux, où (sérialisés) différents modèles de vue ou les Dto sont envoyés à un client. À l'aide de classes de domaine dans l'Isu presque jamais s'inscrit le projet. Vous pouvez ainsi utiliser l'EF classes du domaine, et des services de jeter modèles dédiés et des Otd tel que requis par une INTERFACE utilisateur ou d'un service consommateurs. Une autre couche d'abstraction peut être un fardeau plutôt qu'une bénédiction, si seulement en terme de performance.

Answer 2

À mon avis, le point de l'ensemble de l'aide POCOs comme des entités qui peuvent être persisté est de supprimer la distinction entre les "entités de base de données" et "entités". Les "entités" sont censés être les "entités d'affaires" qui peuvent être conservées et chargées à partir d'une banque de données et agissent donc comme des "entités de base de données" dans le même temps. En utilisant POCOs les entités commerciales sont découplées du mécanisme spécifique pour interagir avec une base de données.

Vous pouvez déplacer les entités dans un projet distinct - par exemple - qui n'a pas de références à tous les EF assemblée et pourtant, leur utilisation dans une base de données de la couche de projet pour gérer la persistance.

Cela ne signifie pas que vous pouvez concevoir votre entreprise entités complètement sans avoir les exigences pour EF à l'esprit. Il y a des limites que vous devez savoir pour éviter les ennuis quand vous venez sur le point de la carte d'affaires des entités à un schéma de base de données à l'aide de EF, par exemple:

• Vous devez faire les propriétés de navigation (références ou des collections de références à d'autres entités) virtual à l'appui de chargement paresseux avec EF
• Vous ne pouvez pas utiliser IEnumerable<T> pour les collections qui doivent être conservés. Il doit être ICollection<T> ou plus de type dérivé.
• Il n'est pas facile à persister private propriétés
• Le type char n'est pas pris en charge par EF et vous ne pouvez pas l'utiliser si vous voulez conserver ses valeurs
• et de plus...

Mais un nouvel ensemble d'entités est - à mon avis - une couche supplémentaire de complexité qui doit être justifiée pour être vraiment nécessaire si les limitations mentionnées sont trop serrés pour votre projet.

YA2C (Encore un autre de 2 cents :))

Answer 3

Je ne sais pas si c'est considéré comme une bonne pratique par les autres, mais personnellement, c'est la façon dont j'ai géré dans le passé:

Les classes générées par EF sont vos DAL, et puis pour les BL créer un ensemble complémentaire de classes dans lesquelles vous aurez la structure dont vous avez besoin (comme peut-être fusionner les données des entités liées dans une relation) et d'autres entreprises de la logique préoccupations sont traitées (validation personnalisée comme la mise en œuvre de IDataErrorInfo pour le faire jouer gentil avec l'INTERFACE utilisateur dans WPF par exemple) et aussi de créer des classes qui contiennent toutes les affaires de la couche de méthodes relatives à un type d'entité, qui utilisent le BL instances et de les convertir vers et à partir de EF entités à la BL objets.

Ainsi, par exemple, vous avez des Clients dans votre base de données. EF va générer une classe Client et, dans le BL, il y aura un Client (préfixe, suffixe, etc.) classe et un CustomerLogic classe. Dans le BL à la Clientèle de classe, vous pouvez faire tout ce qui est nécessaire pour satisfaire les besoins sans avoir à trifouiller dans les EF entités et dans le CustomerLogic classe que vous aurait BL méthodes (charge la plupart des clients, enregistrer les clients avec des données supplémentaires, etc.).

Maintenant, cela vous permet d'être faiblement couplé à la source de données la mise en œuvre. Un autre exemple de pourquoi cela a été bénéfique pour moi dans le passé (dans un projet WPF) est que vous pouvez faire des choses comme mettre en œuvre IDataErrorInfo et de mettre en œuvre la logique de validation de la CustomerBL classes de sorte que lorsque vous lier l'entité à créer/modifier un formulaire sur l'INTERFACE utilisateur vous permettra de bénéficier de la fonctionnalité intégrée fournie par WPF.

...My 2 cents, je suis aussi curieux de savoir quelle est la meilleure pratique ou ce que d'autres solutions/points de vue sont.

---

Peut-être aussi liée à ce sujet - EF de Code 4.1-premier vs/Modèle de Base de données-première

Answer 4

Ce sujet est peut-être un peu vieux mais cela peut aider. Andras Nemes a souligné dans son blog le souci d'utiliser DDD (conception basée sur une base de données) par rapport à la technologie telle que EF, MVC, etc.

http://dotnetcodr.com/2013/09/12/a-model-net-web-service-based-on-domain-driven-design-part-1-introduction/

Answer 5

J'ai utilisé la logique métier pour écrire mes méthodes et renvoyer les résultats dans sa vue créée, comme:

 namespace Template.BusinessLogic
{
    public interface IApplicantBusiness
    {
        List<Template.Model.ApplicantView> GetAllApplicants();

        void InsertApplicant(Template.Model.ApplicantView applicant);
    }
}