Веб-разработка и эффективность внутренних вызовов

Question

Вот сценарий:

У вас есть приложение ASP.Net, поддерживаемое базой данных Microsoft SQL Server, и для этого примера кэширование не будет.

Что эффективнее для каждой страницы в вашем веб-приложении:

Попытка объединить все, что вам нужно, в один (или несколько) вызовов хранимых процедур, которые возвращают несколько таблиц со всеми необходимыми данными (которые вы сохраняете в наборе данных),

или

сделать каждый вызов отдельным (чтение каждого вызова через устройство чтения данных), в зависимости от того, насколько логически это имеет смысл.

Причина, по которой я спрашиваю, заключается в том, что я всегда выполняю все по-другому: создаю простые методы, которые подключаются к базе данных и получают некоторые данные для каждой маленькой задачи, которую я имею (т.е. метод для заполнения определенного выпадающего списка, другой для основного информация для страницы и т. д.).

Меня беспокоит то, что в итоге происходит, когда запрашивается страница, если я посмотрю на SQL Profiler для сервера, в итоге будет около 10 или около того вызовов для этого запроса на одну страницу. Это чрезмерно? На мой взгляд, кажется, что было бы более эффективно сокращать сбор данных по страницам, а не задачам. У кого-нибудь есть опыт с этим?

Answer 1

Не группируйте сбор данных по страницам. Вы слишком тесно связываете данные и презентацию. Что если завтра данные отправятся на разностную страницу?

Answer 2

Большую часть моей ежедневной работы я работаю над огромным приложением WinForms, которое поддерживается базой данных более 600 таблиц SQL Server.

Мы делаем это первым способом минимизации сетевого трафика. Считается, что лучше иметь один выпуклый конверт, чем почтовый мешок, полный конвертов.

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

Answer 3

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

Если ваше приложение вместо этого было клиентским приложением Windows, то может иметь смысл «объединить» вызовы в один, если скорость сети между клиентом и сервером была особенно низкой. Вы работаете с веб-приложением, поэтому здесь уместна соответствующая скорость соединения между веб-сервером и сервером БД, что не должно быть проблемой.

Объединение ваших данных - просто дополнительная работа без отдачи.

Answer 4

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

Но, вообще говоря:

• слишком много вызовов для данных слишком много (sql-соединения и издержки сетевого трафика),

• попытаться получить только то, что вам нужно (если необходимо, получите набор данных, специфичный для вашей страницы),

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

Чтобы добавить к комментариям fallen и edg, вы должны следить за тем, чтобы данные (модель) и страница (представление / представление) были отделены от уровня контроллера. Уровень контроллера может быть сделан для получения данных для представления любым способом, который вы выберете (в зависимости от того, что более эффективно). Этот шаблон (MVC / MVP) позволит вам иметь очень управляемый и многократно используемый код и даст вам больше возможностей для тестирования различных подходов.

Answer 5

Разве это не зависит от того, как часто меняется ваш контент,? Вы можете вывести большую часть своего контента «для XML» и сделать так, чтобы ваш сайт читал xml

Answer 6

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

Имена таблиц моего списка выбора (вымышленные)

• pl_usertypes
• pl_projecttypes
• pl_stattypes

Итак, я создал статический метод GetPicklistData (String [] tablename), который возвратил DataSet. Так что мой метод Page_Load будет выглядеть примерно так:

protected void Page_Load(object sender, EventArgs e)
{
  DataSet ds = PicklistHelper.GetPicklistData(
      new String[]{"pl_usertypes","pl_projecttypes","pl_stattypes"});
  // Bind dropdowns
  ddl_a.DataSource = ds.Tables[0]; // pl_usertypes
  ddl_a.DataBind();

  ddl_b.DataSource = ds.Tables[1]; // pl_projecttypes
  ddl_b.DataBind();

  ddl_c.DataSource = ds.Tables[2]; // pl_stattypes
  ddl_c.DataBind();
}

Поэтому, когда я проверяю SQL Profiler, он читает

Select * from pl_usertypes; Select * from pl_projecttypes; Select * from pl_stattypes;

Так что довольно очевидно, что GetPicklistData () строит мои операторы select.

Возможно, здесь я был "анальным", но я все равно не знаю, почему я смотрел в SQL Profiler. :)