What Project Layer Should Screen DTO's Live In?

Question

I have a project where we use screen DTO's to encapsulate the data between the Service Layer and the Presentation Layer. In our case, the presentation layer is ASP.Net.

The only classes that know about the DTO's are the service layer classes and the Pages/Controls that call these services and display the DTO's.

The DTO's are almost always Page/Control specific so I feel they belong in the Presentation Layer, but that would mean the Service Layer would have to reference the Presentation Layer in order to use the DTO's.

I'm almost thinking that the Service Layer should return richer objects (but not domain entities?) and then the Presentation Layer can take these objects and map them to very specific DTO's for each Page/Control concern.

Here's an interface declaration and a DTO so you can see what I'm talking about:

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; }
}   

Edit

Here's another code sample to describe a use case where the Domain model isn't involved. Maybe this will clarify things a bit. I believe I've overloaded the DTO meaning. I'm not talking about a DTO for the function of transfering an object over the wire. I'm creating DTOs to formalize contracts between communication to my Service Layer.

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; }
}

Let's say my authentication all of the sudden requires an IP address parameter. I can now add that property to the DTO without having to change my contract interface.

I don't want to pass Entities to my Presentation Layer. I don't want my code behind to have the ability to go BlogPost.AddComment(new Comment())

Answer 1

Even thought the canonical use-case for the 'DTO' is more "serializable object that can be passed over the wire", in this case you are really referring more to 'presentation-transfer-objects' or 'view-models'.

Typically for our projects the answer to where these live is where the 'translation' code is that maps the DDD domain model to the PTO classes. If that's in the Prensenation layer (perhaps not so great an answer) then the pres. layer is where I'd declare the PTOs. But more often than not, its the 'Service' that does the translation for you and that means that both the 'Service' and the 'Presentation' layer need references to the PTOs and that (usually) leads to their declaration in a separate, neutral project/assembly/namespace/whatever that BOTH the presentation layer AND the service layer can then reference.