LinqToSQL Design Query / Worry

Question

Интересно, кто-нибудь может указать мне правильное направление? Я недавно начал играть с LinqToSQL и люблю строго типизированные объекты данных и т. Д.

Я просто пытаюсь понять влияние на производительность базы данных и т. Д. Например, скажем, я разрабатывал простую страницу профиля пользователя. На странице отображается основная информация о пользователе, некоторая информация о его недавней активности и список непрочитанных уведомлений.

Если бы я разрабатывал хранимую процедуру для этой страницы, я мог бы создать один SP, который возвращает несколько таблиц данных, охватывающих всю необходимую информацию, что приводит к одному вызову БД.

Однако, используя LinqToSQL, это может привести ко многим вызовам - один для информации о пользователе, по меньшей мере один для активности, по меньшей мере один для уведомлений, если я затем хочу получить дополнительную информацию об уведомлениях, это может привести к дальнейшим вызовам - нескольким вызовам в дБ. 1007 *

Должен ли я беспокоиться о количестве вызовов БД, происходящих в результате использования этого шаблона проектирования? То есть, многократные рукопожатия и т. Д. Будут ухудшать мою базу данных и т. Д.?

Буду признателен за ваши мысли по этому поводу!

Спасибо David

Answer 1

LINQ to SQL может использовать несколько результатов из сохраненного процесса, если вам нужно пойти по этому пути. К сожалению, у дизайнера возникают проблемы с отображением их правильно, поэтому вам, вероятно, придется создавать отображение вручную. Смотри http://www.thinqlinq.com/Default/Using-LINQ-to-SQL-to-return-Multiple-Results.aspx.

Вы можете настроить LINQ to SQL для активной загрузки дочерних записей, если вы знаете, что они понадобятся вам для каждой родительской записи. Используйте DataLoadOptions и .LoadWith для его настройки.

Вы также можете проецировать граф объектов с несколькими дочерними коллекциями в предложении Select запроса LINQ, чтобы уменьшить количество обращений к БД, которые вы делаете.

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

Answer 2

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

Настоящий вопрос в том, вы не возражаете? Будет ли ваше приложение получать достаточное количество посещений, чтобы гарантировать дополнительную сложность хранимой процедуры? Или вы цените простоту будущих модификаций, а не чистую производительность?

В любом случае, если вам нужна производительность, вы можете создать хранимую процедуру и отобразить ее в своем контексте. Это даст вам один единственный вызов, но вернет данные как объекты Вот статья, объясняющая немного об этой опции: LINQ к SQL-возвращающейся-множественный результат-наборы