Недавно наткнулся на одну стетейку и задумался вот над каким вопросом.
Допустим у нас есть сущности Заказ и Товар. В заказе может быть несколько товаров.
В бд такие таблицы:
create table Order (OrderID int, Date datetime) -- заказы
create table Item (ItemID int, Name varchar(10)) -- товары
create table OrderItem (OrderID int, ItemID int) -- связь товара и заказа

И возникает вопрос, как с этой структурой работать и какая должна быть объектная модель?
ORM не использовать. Получение данных из БД при помощи хранимых процедур.

//Вариант1:
public class Item
{
    public int ItemID;
    public int Name;
}
public class Order
{
    public int OrderID;
    public int OrderDate;
}
public class OrderRepository
{
    public Order[] GetOrders()
    public Item[] GetItemsByOrder(int orderID)
}
//Вариант2:
public class Item
{
    public int ItemID;
    public int Name;
}
public class Order
{
    public int OrderID;
    public int OrderDate;
    Item[] Ordertems;
}
public class OrderRepository
{
    public Order[] GetOrders()
}

В варианте2 объекты товар содержаться непосредственно в заказе. Но при получении и отображении списка заказов, мне совершенно не нужно знать их состав. Состав нужет когда из списка выбирается один заказ. Соответвенно тратить время на заполнение внутреннего массива у всех заказов нельзя. С другой стороны, коль скоро уж у объекта есть внутреннее свойство "товары", то при использовании объекта, я ожидаю что оно будет заполнено. Иначе получается использующий код должен знать, как устроен класс заказы и что внутренние позиции заказа не заполняются. Это не есть хорошо. Если добавить вместо внутреннего поля свойство или метод для получения списка позиций заказа, то получится что логика доступа к БД смешивается с бизнес логикой. Тоже хрень какая-то получается.

В первом варианте, получается честнее, т.к. все что у меня есть — это идшка заказа, соответвенно для получения внутренних элементов мне надо обратиться к специальному методу. Но с точки зрения модели предметной области — это решение какое-то неуклюжее, по сути в таком решении "объект" = "запись в бд". Что как бы сводит на нет всю "объектность", как мне кажется.

А как сделано у вас?

пока писал вопрос, подумал, может в первом варианте, при получении списка заказов сделать то самое свойство или метод, но в нем просто вызывать соотв. метод репозитория, тогда вроде как и код доступа к бд разделен с бизнес-логикой и "объектность" сохраняется..или тоже бред? как думаете?