Question

I’m using the PetaPoco mini-ORM, which in my implementation runs stored procedures and maps them to object models I’ve defined. This works very intuitively for queries that pull out singular tables (i.e. SELECT * FROM Orders), but less so when I start writing queries that pull aggregate results. For example, say I’ve got a Customers table and Orders table, where the Orders table contains a foreign key reference to a CustomerID. I want to retrieve a list of all orders, but in the view of my application, display the Customer name as well as all the other order fields, i.e.

SELECT
    Customers.Name,
    Orders.*
FROM
    Orders
    INNER JOIN Customers
        ON Orders.CustomerID = Customers.ID

Having not worked with an ORM of any sort before, I’m unsure of the proper method to handle this sort of data. I see two options right now:

1. Create a new aggregate model for the specific operation. I feel like I would end up with a ton of models in any large application by doing this, but it would let me map a query result directly to an object.
2. Have two separate queries, one that retrieves Orders, another that retrieves Customers, then join them via LINQ. This seems a better alternative than #1, but similarly seems obtuse as I am pulling out 30 columns when I desire one (although my particular mini-ORM allows me to pull out just one row and bind it to a model).

Is there a preferred method of doing this, either of the two I mentioned, or a better way I haven’t thought of?

Answer 1

Option #1 is common in CQRS-based architectures. It makes sense when you think about it: even though it requires some effort, it maps intuitively to what you are doing, and it doesn’t impact other pieces of your solution. So if you have to change it, you can do so without breaking anything elsewhere.