Qu'est-ce que la couche projet devrait Screen Live In de DTO?

Question

J'ai un projet où nous utilisons pour encapsuler les données de l'écran DTO entre les balises Service Layer et couche présentation . Dans notre cas, la couche de présentation est ASP.Net.

Les seules classes qui connaissent de la DTO sont les classes de la couche de service et les Pages / contrôles qui font appel à ces services et affichent de la DTO.

Les DTO de sont presque toujours page / spécifiques de contrôle, donc je pense qu'ils appartiennent à la couche de présentation, mais cela signifierait la couche de service devrait faire référence à la couche de présentation afin d'utiliser la DTO.

Je pense presque que la couche de service doit retourner des objets les plus riches (mais pas des entités de domaine?) Puis la couche de présentation peut prendre ces objets et les associer à très spécifiques DTO pour chaque page / PRÉOCCUPATIONS Contrôle.

Voici une déclaration d'interface et un DTO afin que vous puissiez voir ce que je parle:

public interface IBlogTasks
{
    BlogPostDisplayDTO GetBlogEntryByTitleAndDate(int year, int month, string urlFriendlyTitle);
}

public class BlogPostDisplayDTO 
{
    public string Title { get; set; }
    public DateTime PostDate { get; set; }
    public string HtmlContent { get; set; }
    public string ImageUrl { get; set; }        
    public string Author { get; set; }
    public int CommentCount { get; set; }
    public string Permalink { get; set; }
}   

Modifier

Voici un autre exemple de code pour décrire un cas d'utilisation où le modèle de domaine ne participe pas. Peut-être que cela va clarifier les choses un peu. Je crois que je l'ai surchargée le sens DTO. Je ne parle pas d'un DTO pour la fonction d'un objet de transférer sur le fil. Je crée DTO de formaliser les contrats entre la communication à mon couche de service.

public interface IAuthenticationTasks
{
    bool AuthenticateUser(AuthenticationFormDTO authDTO);
}

public class AuthenticationFormDTO
{
    public string UserName { get; set; }
    public string Password { get; set; }
    public bool persistLogin { get; set; }
}

Disons que mon authentification tout d'un coup nécessite un paramètre d'adresse IP. Je peux maintenant ajouter cette propriété à la DTO sans avoir à changer mon interface de contrat.

Je ne veux pas passer entités à ma couche de présentation. Je ne veux pas que mon code derrière pour avoir la possibilité d'aller BlogPost.AddComment(new Comment())

Answer 1

Même pensé l'utilisation cas canonique pour la « DTO » est plus « objet sérialisable qui peut être transmis sur le fil », dans ce cas, vous faites référence vraiment plus à « objets-transfert-présentation » ou « vue-modèles .

En général pour nos projets, la réponse à l'endroit où ceux-ci vivent est où le code « traduction » est que les cartes du modèle de domaine DDD aux classes de prise de force. Si c'est dans la couche Prensenation (peut-être pas si grande réponse), puis les pres. couche est où je déclare les prises de force. Mais plus souvent qu'autrement, son « Service » qui fait la traduction pour vous et cela signifie que les deux « Service » et la couche « Présentation » ont besoin des références aux prises de force et que (généralement) conduit à leur déclaration dans une procédure distincte, neutre projet / montage / espace / whatever que les deux la couche de présentation et la couche de service peut alors référence.

Answer 2

Utilisez-vous des services réels (web ou WCF)? Si oui, puis définissez les DTO dans la couche de service et le proxy créé lorsque vous ajoutez une référence service (ou web si vous utilisez ancien ASMX) contiendra tous les types DTO. Ceci est la façon la plus simple de le faire et ne maintient que le couplage lâche entre votre projet ASP.NET et votre projet de service - aucune référence directe du projet est nécessaire dans les deux sens. Comme vous mettez à jour votre DTO, tout ce que vous devez faire est de mettre à jour votre référence de service et il exposera automatiquement les mises à jour de votre projet Web via la classe proxy qui est généré.

En tout état de cause, si vous suivez quelque chose comme une approche DDD, il est préférable d'avoir vos projets d'infrastructure (comme une interface spécifique à la plateforme-web) le référencement de vos objets de domaine que vice-versa. Si vous suivez mes conseils ci-dessus, cependant, votre projet web ne sera pas une dépendance directe sur le projet du tout, ce qui est une bonne chose, et certainement mieux que d'avoir vos objets riches de domaine en fonction de votre projet web (si cela même une considération - je vous rends compte que vous ne dites pas été faisiez)

.

Si vos DTO sont des vues spécifiques, alors je les inclure dans votre projet d'interface utilisateur. Il devrait vraiment être le travail du contrôleur pour faire en sorte que la vue ne reçoit que du modèle ce dont il a besoin -. Dans votre cas une valeur objet avec seulement les champs nécessaires à la vue