J'ai une application MVC2 n-tier (DAL, domaine, service, web MVC) en utilisant une approche DDD (Domain Driven Design), ayant un modèle de domaine avec référentiels. Ma couche de service utilise un modèle de requête/réponse , dans lequel les objets Request et Response contiennent des objets DTO (Data Transfer Objects) pour rassembler les données d'une couche à la suivante et le mappage est effectué via l'aide d'AutoMapper. Ma question est la suivante: quelle forme devrait normalement prendre un DTO? Peut-il avoir imbriqué/complexe DTO aussi bien ou devrait-il être strictement une plate projection? Ou peut-être un mélange des deux? En outre, quelles sont les principales raisons d'avoir un DTO plat par rapport à un DTO plus complexe/imbriqué?Forme DTO: plate, complexe/imbriquée, ou un mélange des deux
Par exemple, supposons que j'avais un domaine tel que:
public class Employee
{
public string FirstName { get; set; }
public string LastName { get; set; }
public Company Company { get; set; }
}
public class Company
{
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string State { get; set; }
}
Il existe trois façons différentes que j'ai pensé de modéliser l'objet Response.
Option 1 - l'option plus sec:
public class GetEmployeeResponse
{
public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}
De la recherche que je l'ai fait, il serait inapproprié pour un DTO de prendre une forme similaire à l'objet de domaine (s) comme démontré ci-dessus .
Option 2 - une projection aplatie du domaine (anti-DRY):
public class GetEmployeeResponse
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string CompanyName { get; set; }
public string CompanyAddress { get; set; }
public string CompanyCity { get; set; }
public string CompanyState { get; set; }
}
Ceci est plus simple, comme un DTO devrait apparemment être, mais en fin de compte fait pour plus DTO.
Option 3 - un mélange des deux:
public class GetEmployeeResponse
{
public EmployeeDTO Employee { get; set; }
public CompanyDTO Company { get; set; }
}
Cela permet le code d'être un peu plus sec, réutilisable et facile à gérer, et ne pas exposer ma structure de domaine à l'utilisateur final . L'autre avantage principal est que d'autres réponses, comme GetCompanyResponse
pourraient simplement retourner CompanyDTO
, sans avoir à faire une copie de toutes ces propriétés, semblable à l'option 2. Que pensez-vous? Quelle option avez-vous prise et/ou avez-vous utilisée pour vous? Si ces demandes/réponses sont exposées ultérieurement en tant que méthodes de service WCF, votre réponse change-t-elle?
Pourquoi construire une application MVC n-tier en premier lieu? Je ne dis pas que c'est faux. Juste être curieux quel avantage vous obtenez en mettant des services entre votre modèle de domaine et le niveau Web –
Je veux juste répondre à un commentaire spécifique que vous avez fait: "faire une copie de toutes ces propriétés". Une fois que votre système atteint un certain seuil de complexité, il peut être préférable d'avoir un modèle de lecture dédié qui est dénormalisé au niveau de la base de données (soit par des vues, soit à votre configuration ORM). Quand j'ai commencé à faire cela, cela m'a permis de construire des modèles de domaines beaucoup plus complexes parce que je n'avais pas à m'inquiéter du coût de l'hydratation pour les requêtes.Je veux dire, pourquoi hydrater plusieurs modèles si vous allez juste les dénormaliser? Laissez la DB faire cela. C'est ce que c'est bon de toute façon. – Ryan
@Szymon Il y a BEAUCOUP d'avantages à avoir un niveau de service. Pour moi, le plus grand avantage est que je peux mettre toute la sécurité dans une couche et ne pas laisser couler dans mes contrôleurs. – Ryan