Я иду против структуры здесь, но я бы сказал, что лучше было бы сохранить отображение этого объекта на наборе результатов и объединение в базе данных.
Для бизнес-логики «заказ» - это, как правило, единое связное понятие (по крайней мере, именно так вы начали его формировать). Может ли тот факт, что он отображается в нескольких таблицах (или базах данных) быть артефактом сбора данных? Я хотел бы задать себе эти вопросы, прежде чем разбить его:
- Есть ли ощутимые преимущества при составлении заказа из других объектов?
- Имеют ли атрибуты различную мощность? То есть некоторые за заказ и другие за позицию?
- Можете ли вы повторно использовать существующий код для составных объектов?
- Включаете ли вы какое-либо другое взаимодействие, которое легче выполнять с несколькими объектами?
Если вы не ответите «да» ни на один из этих вопросов, я держу пари, что ваш код будет более простым и более читабельным, если он будет работать только с порядком в качестве атомарного объекта и позволит базе данных скрыть сложность того, где он находится. исходя из (вы могли бы даже использовать представление для этого).
Само по себе количество атрибутов обычно не является причиной для разрушения интерфейса. Но, если сложность (или размер) самого объекта заказа вызывает у вас недостаток, вы можете попытаться упростить его внутренне, чтобы использовать какой-то универсальный метод доступа, такой как:
private object GetOrderAttribute(string attributeName){
// use a data structure (like a hash table) to store and access internally
}
...
output("Quantity: " + GetOrderAttribute("quantity"));
// etc.
Еще одно замечание: хотя производительность редко должна быть вашей начальной заботой при проектировании логической системы, большинство случаев, связанных с объединением таблиц базы данных, будет работать лучше, если база данных выполнит объединение, потому что СУБД может использовать индексы и другие механизмы для эффективного объединения и предотвращения загрузки ненужных страниц с диска. Может быть, все ваши индивидуальные запросы тоже это делают, но обычно это то, что база данных может выполнять на порядок эффективнее, чем код бизнес-логики. (Конечно, если соединение выходит за физические границы базы данных, это преимущество может быть потеряно.)