Загрузка иерархии бизнес-объектов с помощью одного вызова базы данных

DataReader NextResult - лучший вариант, поскольку объем данных, проходящих по каналу, не растет так быстро, как это может сделать подход соединения.

Раньше я использовал несколько возвращаемых наборов данных, но накладные расходы и постоянно меняющиеся API для этого наконец позволили мне вернуться к использованию только объединений, чтобы вернуть все это одним глотком.

Я слежу за размерами набора результатов, но в контексте любого приложения, с которым я сталкивался, это не было проблемой. В целом я не пожалел об этом, но YMMV.

Множественные наборы результатов могут быть получены особенно быстро, если предложения выбора родительского уровня включают правила выбора дочернего уровня.

Таким образом обрабатываются все случаи; его разделение иногда работает, но в некоторых случаях вам могут понадобиться запросы с одним набором; и хорошо иметь только один шаблон - особенно если вы иногда застреваете при рефакторинге от одного к другому.

В итоге вы получаете меньше обращений к базе данных, а управление транзакциями становится проще.

Универсального рецепта нет. Это зависит от схемы базы данных, размера базы данных и количества записей, которые ваше приложение читает в типичном сценарии. Здесь у вас есть два процесса:

• получение данных из базы данных
• заполнение бизнес-объектов

Получение данных из базы данных на несколько порядков медленнее, чем создание объектов в памяти. Лучшим способом было бы создать операторы выбора для максимально быстрого доступа к данным.

Запросы можно строить тремя способами:

• один большой запрос, который извлекает все за одно выполнение - вы получите самый сложный SQL и, вероятно, самое быстрое выполнение (зависит от схемы БД)
• мастер / подробный подход - простые запросы. большой трафик к базе данных. Это приемлемо, только если вы получаете небольшое количество записей, в противном случае это очень медленно.
• гибрид: по одному запросу для каждого уровня иерархии. Рассмотрите этот подход, если предыдущие два метода работают медленно. Этот подход требует более сложной логики для заполнения бизнес-объектов.

Вы должны решить, какое решение приемлемо. Некоторые ключевые моменты, которые следует учитывать:

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

Вы рассматривали возможность использования OR Mapper, такого как NHibernate? Активная загрузка может сделать то, что вы просите, за один вызов базы данных.

Если OR Mapper не подходит, я бы проголосовал за datareader.NextResultSet.

если все строки взяты из одной таблицы (или кажутся), то вы можете вытащить данные в набор данных с унарными отношениями, и ADO.NET свяжет для вас иерархию