什么项目层应屏幕DTO的住呢？

Question

我在这里我们使用的屏幕DTO的到服务层之间封装数据的项目，并在表现层。在我们的情况下，表示层是ASP.Net。

这了解DTO的唯一的类是服务层类和调用这些服务，并显示页/控制中的DTO的。

在DTO的几乎都是页/控制专用的，所以我觉得他们属于在表示层，而这将意味着业务层就必须引用表现层，以使用DTO的。

我几乎想，业务层应该返回丰富的对象（但不是域实体？），然后表示层可以采取这些对象并将其映射到DTO的非常具体的每一页/控制问题。

下面是一个接口声明和DTO，所以你可以看到我在说什么：

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

修改

这里的另一个代码示例来描述，其中不参与域模型的使用情况。也许这将澄清事情有点。我相信我已经超载的DTO意义。我不是在谈论一个DTO用于在电线transfering对象的功能。我创建DTO的正式沟通之间的合同到我的服务层。

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

比方说，我的身份验证所有的突然需要一个IP地址参数。我现在可以添加属性的DTO，而无需改变我的合同接口。

我不想实体传递给我的表示层。我不希望我的背后的代码必须去BlogPost.AddComment(new Comment())的能力

Answer 1

甚至认为规范的用例为“DTO”更“它可以通过线路传递序列化对象”，在这种情况下，你真的谈得更多的是“演示转移对象”或“视图模型”。

通常我们的项目回答这些住的地方是在“翻译”的代码是，DDD领域模型映射到PTO类。如果这是在Prensenation层（也许没有那么大的一个答案），那么PRES。层是我想声明的PTO。但更多的，往往不是它，做翻译为你“服务”，这意味着，无论是“服务”和“演示”层需要在取力器的引用和（通常）导致其声明在一个单独的，中性项目/组件/命名空间/不管的是，表示层和服务层可以再参考。

Answer 2

您使用的实际服务（Web或WCF）？如果是的话，那么当你（如果使用旧的ASMX或网页）引用将包含所有的DTO类型的添加服务定义在服务层，并建立了代理的DTO。这是做的最简单的方法，并保持你的ASP.NET的项目和服务项目之间只有松散的耦合 - 没有直接的项目引用在任何一个方向是必需的。当你更新你的DTO，所有你需要做的就是更新您的服务引用，它会通过所产生的代理类自动暴露更新到Web项目。

在任何情况下，如果你是以下有点像DDD的方法最好是有你的基础设施项目（如特定的网络平台，UI）引用您的域对象不是相反。如果你按照我上面的建议，不过，你的web项目不会对这个项目都直接依赖关系，这是一件好事，并且肯定比具有取决于你的web项目中的丰富的域对象（如果这是更好考虑 - 我知道你不是说你在做这个）

。

如果您的DTO是特定视图，然后我就包括他们在您的UI项目。它应该是控制器的工作，以确保只查看从它所需要的模式得到 - 你的情况的值对象只通过视图所需要的领域