For me, it comes down to two things: 1) being DRY, and 2) testability. If I find that I have to write that same query again, I will refactor so that it’s in one place. For testability, if I go through another layer of abstraction, I can mock out that layer to make sure that my controller is working properly. In Matt’s example, I can mock out the Ship method to return different statuses, and ensure that my controller is redirecting how it is supposed to.

This is annoying, but it depends. If the semantics of the linq query are clear and it’s concise.. why not use it? I think I would default to the linq query.. but there’s a pain/maintainability threshold that will be met soon in a larger project. And so I’d keep an eye on that. I think in the next year or so we’ll see an alternative that is something like query object (but not query object) that we might like better than the OCP-violating repository methods.

public JsonResult FindShipsByOrderId(int orderId)
{
return s.Linq().Where(….).Select(c=> new { ShipId= c.shipId, …});
}

or

public JsonResult FindShipsByOrderId(int orderId)
{
return orderShippingService.FindShipsByOrderId(orderId);
}