Entités ORM vs entités de domaine sous Entity Framework 6.0
Je suis tombé sur les deux articles suivants First et Second dans lesquels l'auteur déclare en résumé que les entités ORM et les entités de domaine ne doivent pas être mélangées.
Je fais face exactement à ce problème en ce moment alors que je code avec EF 6.0 en utilisant l'approche Code First. J'utilise les classes POCO en tant qu'entités dans l'EF ainsi que mes objets domaine/métier. Mais je me retrouve fréquemment dans la situation où je définis une propriété comme publique ou une propriété de navigation comme virtuelle uniquement parce que le cadre EF m'y oblige.
Je ne sais pas quoi prendre comme résultat final des deux articles? Dois-je vraiment créer par exemple une classe CustomerEF pour le framework d'entité et un CustomerD pour mon domaine. Ensuite, créez un référentiel qui consomme CustomerD le mappe à CustomerEF, effectuez quelques requêtes et ensuite mappez le CustomerEF reçu à CustomerD. Je pensais que EF consistait à mapper mes entités de domaine aux données.
Alors donnez-moi quelques conseils. Est-ce que j'oublie une chose importante que l'EF peut me fournir? Ou est-ce un problème qui ne peut pas être complètement résolu par l'EF? Dans ce dernier cas, quelle est la bonne façon de gérer ce problème?
Je suis d'accord avec l'idée générale de ces postes. Un modèle de classe ORM fait d'abord et avant tout partie d'une couche d'accès aux données (même s'il est constitué de soi-disant POCO). En cas de conflit d'intérêts entre la persistance et la logique métier (ou toute autre préoccupation), les décisions doivent toujours être prises en faveur de la persistance.
Cependant, en tant que développeurs de logiciels, nous devons toujours trouver un équilibre entre purisme et pragmatisme. L'utilisation ou non du modèle de persistance comme modèle de domaine dépend d'un certain nombre de facteurs:
La taille/cohérence de l'équipe de développement. Lorsque toute l'équipe sait que les propriétés peuvent être publiques uniquement en raison des exigences ORM, mais ne doivent pas être définies partout, ce n'est peut-être pas un gros problème. Si tout le monde sait (et obéit) qu'une propriété ID ne doit pas être utilisée dans la logique métier, avoir des ID peut ne pas être un gros problème. Une équipe dispersée, inexpérimentée ou indisciplinée peut avoir besoin d'une ségrégation plus stricte du code.
Le chevauchement entre les préoccupations de logique métier et les préoccupations de persistance. La conception orientée objet prospère lorsqu'un modèle de classe s'en tient aux principes SOLIDES . Mais ces principes ne sont pas nécessairement en contradiction avec les préoccupations de persistance. Je veux dire que bien que les préoccupations soient différentes, en fin de compte, les exigences qui en découlent peuvent être assez similaires. Par exemple, les deux problèmes peuvent nécessiter un état d'objet valide et des associations correctes.
Il peut cependant y avoir des cas d'utilisation dans lesquels les objets doivent temporairement être dans un état qui ne doit absolument pas être stocké. Cela peut être une raison pour travailler avec des classes de domaine dédiées. Une autre raison peut être que le modèle d'entité ne peut tout simplement pas assurer la meilleure segmentation des responsabilités. Par exemple, un processus métier de "mise sur liste noire de clients" peut nécessiter des données dispersées sur un si grand nombre d'objets d'entité que de nouvelles classes de domaine doivent être conçues pour encapsuler les données et les méthodes qui les utilisent. En d'autres termes: faire cela par des entités violerait le principe Tell Don't Ask .
Le besoin de superposition. Par exemple, si la couche d'accès aux données cible différents fournisseurs de bases de données, elle peut être constituée de parties interchangeables spécifiques au fournisseur (par exemple pour tenir compte des différences subtiles dans les types de données entre Oracle et SQL Server ou pour exploiter les fonctionnalités spécifiques au fournisseur). L'utilisation du modèle de persistance comme modèle de domaine entraînerait probablement des implémentations spécifiques au fournisseur dans la logique métier. Ce serait vraiment mauvais. Là, la couche d'accès aux données devrait être précisément cela, une couche.
(Très trivial) La quantité de données. La création d'objets prend du temps et des ressources. Lorsque "de nombreux" objets sont impliqués dans une analyse de rentabilisation, il peut être trop coûteux de créer à la fois des objets d'entité et des objets de domaine.
Et plus, sans aucun doute.
J'essaierais donc toujours d'être pragmatique. Si les classes d'entités font un travail décent, allez-y. Si la non-concordance est trop importante, créez un domaine métier pour les parties appropriées de la logique métier. Je ne suivrais pas servilement un (n'importe quel) modèle de conception simplement parce que c'est un bon modèle. Contrairement à ce qui est dit dans la publication, il faut beaucoup de maintenance pour mapper un modèle d'entité sur un modèle d'entreprise. Lorsque vous vous retrouvez à créer des myriades de classes affaires qui sont presque identiques aux classes d'entités, il est temps de repenser ce que vous faites.