在ServiceStack模型中处理聚合

我正在开发基于ServiceStack的项目，该项目有一个MVC Web应用程序和一些作为Azure webjobs运行的消息传递/轮询应用程序。该项目使用this SO question中推荐的一般结构，但我发现我的一些要求不太适合。在ServiceStack模型中处理聚合

具体来说，建议如何处理模型中的聚合体？例如，假设我想有一个Statistics模型看起来是这样的：

public class Statistics 
{ 
    public int TotalCompletedSessions { get; set; } 
    public int TotalAbandonedSessions { get; set; } 

    public int AverageSessionDuration { get; set; } 
    public int MaxSessionDuration { get; set; } 
}

这是一个简单的例子，但我会好起来创建一个StatisticsRequest类将返回StatisticsResponse DTO，与我的服务接口使用OrmLite来拉一个查询，将返回聚合？或者我应该让服务变得超级RESTful，并专注于只提供资源（在上面的示例中，完整的Session对象），并使用某种业务逻辑层计算这些聚合？

如果是后者，业务逻辑应该在哪里存在，并且是否可以/应该向外部客户提供？

来源

2015-12-02 Josh Anderson

我推荐以下a YAGNI approach，并始终努力寻求最简单的解决方案，尽可能少的工作，抽象和间接所需，在这种情况下，这听起来像是一个OrmLite查询。

来源

2015-12-02 21:58:06 mythz

谢谢@mythz。你认为有一个专门的请求/响应DTO是有意义的，即使像这样的聚合对象本身不是一个*资源*本身？或者我最好只是拉取一些资源并在客户端进行计算？我在真正的蓝色REST和简单/高效之间徘徊。 –

@Josh永远采取简单/高效的选择，您的客户总能从更好的性能/响应能力中受益，并且每当您节省开发时间时，您都可以用它来增加价值。浪费时间/精力试图过度设计它几乎没有什么实际好处。 – mythz

在ServiceStack模型中处理聚合

回答

相关问题