0

I'm working on a ServiceStack-based project that has an MVC web app and some messaging/polling apps that run as Azure webjobs. The project uses the general structure recommended in this SO question, but I'm finding that some of my requirements don't fit particularly well.

Specifically, what is the recommended way to handle aggregates in models? For example, let's say I want to have a Statistics model that looks something like this:

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

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

This is a simplistic example, but would I be better off to create a StatisticsRequest class that would return a StatisticsResponse DTO, with my service interface using OrmLite to pull a query that would return the aggregates? Or should I just have the service be super-RESTful and focus on delivering only resources (in the example above, full Session objects) and calculate those aggregates using some sort of business logic layer?

If the latter, where should that business logic exist, and could/should it be available to external clients?

Community
  • 1
  • 1
Josh Anderson
  • 5,975
  • 2
  • 35
  • 48

1 Answers1

0

I'd recommend following a YAGNI approach and always strive for the simplest solution that works with least effort, abstraction and indirection required, which in this case sounds like a single OrmLite query.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390
  • Thanks @mythz. You think it would make sense to have a dedicated request/response DTO even though an aggregate object like this isn't exactly a *resource* per se? Or am I better off just pulling a collection of the resources and doing the calculations at the client? I'm torn between true-blue REST and easy/efficient. – Josh Anderson Dec 03 '15 at 14:33
  • @Josh Always take the easy/efficient option, your Customers always benefit from better perf/responsiveness and any time you save on dev you can spend on adding value. There's little tangible benefit in wasting time/energy trying to over design it. – mythz Dec 03 '15 at 14:39