nhibernate et DDD suggestion

Question

Je suis assez nouveau à nHibernate et DDD, alors s'il vous plaît ours avec moi.

Je dois créer un nouveau rapport à partir de ma table SQL. Le rapport est en lecture seule et sera lié à un contrôle GridView dans une application ASP.NET.

Le rapport contient les champs suivants: Style, Couleur, Taille, LAQty, MTLQty, Statut. J'ai les entités pour Style, Couleur et Taille, que j'utilise dans d'autres pages asp.net. Je les utilise via des dépôts. Je ne suis pas sûr Si vous devez utiliser les mêmes entités pour mon rapport ou non. Si je les utilise, où dois-je cartographier les champs Qté et Statut?

Si je ne devais pas utiliser les mêmes entités, devrais-je créer une nouvelle classe pour le rapport? Comme je l'ai dit, je suis nouveau à cela et j'essaie juste d'apprendre et de coder correctement.

Merci

Answer 1

Pour les rapports est plus facile à utiliser généralement des valeurs simples ou DTO spéciale de. Bien sûr, vous pouvez interroger l'entité qui référence toutes les informations, mais pour la mettre dans la liste (par exemple en utilisant la liaison de données), il est plus pratique d'avoir une seule classe qui contient toutes les valeurs.

Pour obtenir des solutions plus spécifiques que les quelques ci-dessous, vous devez nous en dire un peu plus sur votre modèle de domaine. À quoi ressemble le modèle de classe?

Généralement, vous avez au moins trois options pour obtenir des valeurs "simples" à partir de la base de données à l'aide de NHibernate.

Ecrire HQL qui retourne un tableau de valeurs

Par exemple:

select e1.Style, e1.Color, e1.Size, e2.LAQty, e2.MTLQty 
from entity1 inner join entity2 
where (some condition) 

le résultat sera une liste d'objets []. Chaque élément de la liste est une ligne, chaque élément de l'objet [] est une colonne. C'est tout à fait comme sql, mais à un niveau supérieur (vous décrivez la requête au niveau de l'entité) et est indépendant de la base de données.

Ou vous créez un DTO (objet de transfert de données) afin de maintenir une ligne du résultat:

select new ReportDto(e1.Style, e1.Color, e1.Size, e2.LAQty, e2.MTLQty) 
from entity1 inner join entity2 
where (some condition) 

ReportDto besoin de mettre en œuvre un constructeur qui a tous ces arguments. Le résultat est une liste de ReportDto.

Ou vous utilisez CriteriaAPI (recommandé)

session.CreateCriteria(typeof(Entity1), "e1") 
    .CreateCriteria(typeof(Entity2), "e2") 
    .Add(/* some condition */) 
    .Add(Projections.Property("e1.Style", "Style")) 
    .Add(Projections.Property("e1.Color", "Color")) 
    .Add(Projections.Property("e1.Size", "Size")) 
    .Add(Projections.Property("e2.LAQty", "LAQty")) 
    .Add(Projections.Property("e2.MTLQty", "MTLQty")) 
    .SetResultTransformer(AliasToBean(typeof(ReportDto))) 
    .List<ReportDto>(); 

Le ReportDto doit avoir un proeprty avec le nom de chaque alias "Style", "couleur", etc. La sortie est une liste de ReportDto.

Answer 2

Je ne suis pas exactement dans DDD, mais j'ai toujours modélisé mes noms comme types et je suis surpris que le rapport lui-même soit une entité. DDD ou non, je ne ferais pas cela, plutôt que mes rapports reflètent les résultats d'une requête, dans laquelle la quantité est probablement count (*) ou somme (lineItem.quantity) et le statut est également calculé (peut-être, en la page).

Vous n'avez pas décrit votre domaine, mais il y a un indice sur ces en-têtes de colonne que vous pouvez faire pivoter les données pour créer LAQty, MTLQty que vous trouverez difficile à faire dans nHibernate comme conçu pour OLTP et ne fait même pas UNION dernière que j'ai vérifié. Cela dit, il n'y a rien de mal à abuser de HQL (Hibernate Query Language) pour faire des rapports légers, tant que vous comprenez que vous en abusez.

Je vois Stefan a fait un grand travail de décrire la syntaxe pour cela, donc je vais arrêter là :-)