Les meilleures pratiques pour gérer les entités tout en interrogeant les données hors des tables?
c# dapper design-patterns domain-driven-design poco
Question
Chaque table de ma base de données a sa propre classe POCO . Maintenant, j'ai commencé à écrire des jointures SQL complexes et le jeu de résultats de la requête doit être mappé sur une entité qui peut être envoyée au Business Manager (une autre couche) pour un traitement ultérieur. Par exemple, imaginez que ma requête renvoie les colonnes comme ceci (le nom de la table est précédé du nom de la colonne pour simplifier):
Customer.CustomerId,
Customer.CustomerName,
Customer.CustomerAddress,
[User].UserId,
[User].UserName,
[User].FirstName,
[User].LastName,
UserRole.RoleId,
UserRole.RoleName,
Employee.EmployeeId,
Employee.EmployeeName,
Employee.JoinDate,
MAX(AuditTrail.LastLoginDate)
etc
Des questions:
- Quel modèle de design dois-je utiliser?
- Je devrais être capable d'écrire plusieurs requêtes avec un tas de colonnes de mix and match récupérées sur chaque requête. Peut-être pas une bonne idée de faire correspondre ce type de jeu de résultats aux classes POCO?
- Je peux avoir d'autres requêtes avec plus ou moins le même type de colonnes nécessaire pour retourner du jeu de résultats SQL.
- Dois-je maintenir des entités séparées uniquement pour prendre en charge les requêtes?
Remarque: J'utilise Dapper ORM pour parler à SQL Server 2012 avec .NET 4.5 Framework (C #). S'il vous plaît laissez-le savoir, si la question n'est pas claire.
Réponse acceptée
Le modèle que vous recherchez est Data Mapper
Une couche de Mappers (473) qui déplace les données entre les objets et une base de données tout en les maintenant indépendants les uns des autres et du mappeur lui-même.
Cela signifie que les éléments extérieurs à votre couche de persistance ne doivent rien savoir de la base de données - ni les frameworks ORM ni les POCO qui imitent une structure de table.
Donc, dans le contexte de DDD, cela signifie que vous utilisez un modèle de domaine et mappez les DB POCO avec ce modèle de domaine. Le mappeur de données est responsable de ce mappage.
la mise en oeuvre
Vous pouvez bien sûr faire le mappage vous-même: Créez une méthode dans le mappeur de données qui prend un DB POCO et retourne l'objet de domaine correspondant. Si vous avez beaucoup de correspondances, cela nécessite beaucoup de code standard.
Pour atténuer ce problème , utilisez une bibliothèque de mappage d'objet à objet telle qu'AutoMapper . Cela réduit la quantité de code que vous écrivez pour un mappage et rend les mappages plus faciles à gérer. L'inconvénient est que vous devez apprendre une nouvelle bibliothèque et en prendre une dépendance.
DB POCO Management
Vos DB POCO (appelés DTO) ne devraient servir qu’à une seule fin: décrire la structure d’une table ou un ensemble de résultats dans le monde C # - rien de plus, rien de moins. Donc, oui, créez un DB POCO par requête qui renvoie une structure de résultat différente.
Réponse populaire
1) Les modèles de référentiel et d'unité de travail conviennent pour traiter les opérations CRUD de base de données. 2 + 4) DTO et POCO sont fondamentalement la même chose. où DTO est généralement un POCO utilisé pour stocker des données. Il est conseillé de les utiliser car vous savez toujours ce que vous avez dans l'objet à utiliser. Si vous construisez votre DTO en fonction des besoins de votre entreprise et non des exigences de la base de données, vous n'aurez pas à le changer la plupart du temps 3) Quelle est la question?
PS En ce qui concerne l'utilisation de SQL dans un environnement .Net, je vous recommande d'utiliser le projet de base de données SSDT pas si nouveau. Cela vous aidera à suivre votre schéma
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow