处理ServiceStack模型中的聚合

Question

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

具体来说，在模型中处理聚合的推荐方法是什么？例如，让我们说我想拥有一个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对象）并使用某种业务逻辑层计算这些聚合？

如果是后者，那么业务逻辑应该存在于哪里，是否可以/应该可供外部客户使用？

Answer 1

我建议关注a YAGNI approach并始终努力寻找最简单的解决方案，该解决方案需要最少的努力，抽象和间接，在这种情况下听起来像一个OrmLite查询。