Моделирование совокупного результирующего набора в (мини) ORM

Question

Я использую мини-ORM PetaPoco, который в моей реализации запускает хранимые процедуры и сопоставляет их с объектными моделями, которые я определил. Это работает очень интуитивно для запросов, которые извлекают единичные таблицы (т.е. SELECT * FROM Orders), но меньше, когда я начинаю писать запросы, которые извлекают совокупные результаты. Например, допустим, у меня есть таблица Customers и таблица Orders, где таблица Orders содержит ссылку на внешний ключ для CustomerID. Я хочу получить список всех заказов, но в представлении моего приложения отобразите имя клиента, а также все остальные поля заказов, т.е.

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

Поскольку раньше я не работал с ORM любого вида, я не уверен в правильном способе обработки данных такого рода. Я вижу два варианта прямо сейчас:

1. Создать новую агрегатную модель для конкретной операции. Мне кажется, что в результате я получу массу моделей в любом крупном приложении, но это позволит мне отобразить результат запроса непосредственно на объект.
2. Иметь два отдельных запроса: один для получения заказов, другой для поиска клиентов, а затем присоединиться к ним через LINQ. Кажется, это лучшая альтернатива, чем № 1, но аналогичным образом выглядит тупо, поскольку я вытаскиваю 30 столбцов, когда мне это нужно (хотя мой конкретный мини-ORM позволяет мне вытянуть только один ряд и привязать его к модели).

Есть ли предпочтительный способ сделать это, либо из двух, которые я упомянул, или лучший способ, о котором я не думал?

Answer 1

Вариант № 1 распространен в архитектурах на основе CQRS.Это имеет смысл, когда вы думаете об этом: даже если это требует определенных усилий, оно интуитивно соответствует тому, что вы делаете, и не влияет на другие части вашего решения.Поэтому, если вам нужно изменить это, вы можете сделать это, не нарушая ничего в другом месте.