我已经看到了很多ServiceStack服务的例子,我似乎不知道何时使用DTO以及何时使用模型。据我了解,DTO将尽可能保持一切,因为这是您的服务合同。这将允许您在代码中进行大量更改,但保持DTO不变。但是如果你有一个Model作为属性之一或它的返回值(在我看到的很多例子中),对模型的依赖是有任何方式的,那么为什么不简单地将模型包装在DTO中以获取请求还有吗?
[Route("/events", "POST")]
public class CreateEvent : IReturn<Event>
{
public string Name { get; set; }
public DateTime StartDate { get; set; }
}
来自:Recommended ServiceStack API Structure
/// <summary>
/// Define your ServiceStack web service response (i.e. Response DTO).
/// </summary>
public class MovieResponse
{
/// <summary>
/// Gets or sets the movie.
/// </summary>
public Movie Movie { get; set; }
}
答案 0 :(得分:1)
对于数据模型,您可以使用不同的DTO,这些数据模型可替代可序列化的DTO,例如:
当使用像OrmLite这样的代码优先的ORM时,这不是一个问题,因为他们鼓励使用干净的POCO已经使得好的候选者被重新用作DTO。
理想情况下,DTO应该是自描述的和非分层的(即扁平的),不依赖于序列化器特定的功能,抑制可重用性并降低与不同格式和序列化器的互操作性。
您的数据模型可能会使用对数据库外部的外部用户没有意义的内部代码(例如int值),在这种情况下,您可能希望将它们投影到自我描述的DTO中,从而使用户更友好标签。
只要您需要在模型之间重新投影,就可以使用Auto Mapping来减少工作量。