Большое старое "это зависит"
Это то, что, в конце концов, вам нужно будет выбрать и посмотреть, как это работает с вашими конкретными данными и потребностями пользователей. Это в некоторой степени касается и сетевых проблем, таких как задержка. В очень хорошей сетевой среде, такой как топ-3 страховой компании, в которой я был сетевым администратором, вы можете добиться сверхнизкой задержки сетевых вызовов. В таком случае множественные сетевые запросы будут значительно отличаться от того, что может быть в домашней интернет-среде. Даже в этом случае вы должны рассмотреть широкий спектр возможностей. И вам ВСЕГДА нужно учитывать ваши конечные цели.
(Не будем слишком углубляться в технические аспекты, но задержку можно довольно точно определить как «время, в течение которого вы ожидаете сетевого запроса, чтобы фактически начать отправку данных». Классический пример того, где это может быть важно, — онлайн-шутер от первого лица. игры.Вы нажимаете «стрелять», а данные передаются не так быстро, как хотелось бы, так как сеть ожидает отправки данных, а затем вы умираете.Классический пример, когда полоса пропускания более полезна, чем задержка, — загрузка или выгрузка больших файлов.Если вам нужно подождать секунду или две, чтобы фактические данные переместились, но когда они перемещаются, вы можете загрузить ГБ за секунды, тогда да ладно, я возьму это.)
В настоящее время у меня есть наш веб-сайт, который делает несколько вызовов для загрузки динамических меню и динамического контента. Это очень маленькие данные. Это делается в три отдельных вызова. В Интернете. Это "хорошо", но я бы не сказал, что "хорошо". Поскольку пользователи ждут, пока все это не начнется, я мог бы также бросить все это в один сетевой вызов. Кроме того, если два звонка проходят нормально, то третий немного подтормаживает, пользователь может начать перемещаться, затем всплывает больше меню, и это не идеально. Вот почему независимо от этого вы должны думать о своих конкретных потребностях и о том, какой диапазон возможных вариантов использования может применяться. (В настоящее время я все равно переписываю весь сайт)
Как говорилось в предыдущем (на мой взгляд, «хорошем») ответе, вероятно, имеет смысл получить весь набор данных одним глотком. Мне кажется, что это внутреннее или, по крайней мере, коммерческое приложение с приличной сетью и, что более важно, без риска потерять клиентов из-за того, что ваши материалы загружались не очень быстро.
Тем не менее, если с этим ничего не получится, особенно если вы говорите о больших наборах данных, рассмотрите архитектуру отложенной загрузки. Например, ваш пользователь не может добраться до сотрудника, пока не увидит отделы. Таким образом, может быть нормально, в зависимости от вашей сети и большого размера данных, загрузить отделы, а затем после возврата инициировать асинхронную загрузку данных о сотрудниках. Данные о сотрудниках теперь загружаются, пока ваш пользователь просматривает названия отделов.
Огромный вопрос, который вы, возможно, захотите уточнить, заключается в том, отображаются ли какие-либо данные списка сотрудников с отделами. В одном из моих случаев у меня есть система заказов на работу, которую я загружаю после входа в систему, но она ленива, и когда она загружается, она выводит значок в меню заказов на работу, чтобы показать, сколько еще не выполнено. Поскольку у меня не так много заказов, это в основном одна секунда ожидания. Ничего страшного. Пользователь не должен ждать, пока он загрузится, чтобы начать работу. Если вам нужен значок для каждого отдела, это может показаться странным. Вы могли бы, если вы загружаете по отделам, иметь несколько значков случайным образом. В этом случае это может вызвать путаницу у пользователя, и, вероятно, будет хорошим выбором загружать его одним большим фрагментом. Если пользователю все равно приходится ждать, он может произвести на один вызов меньше, когда пользователь спрашивает: «Это нормально, что он это делает?». Особенно с программным обеспечением для рабочего места более приемлемо ждать первоначальной загрузки в начале рабочего дня.
Чтобы быть ясным, со всеми этими сложностями, чрезвычайно важно, чтобы вы разрабатывали с настолько хорошими методами кодирования программного обеспечения, насколько это возможно. Таким образом, вы можете закодировать одно решение, и если оно не соответствует вашей производительности или потребностям пользователя, внесение изменений не станет кошмаром. В общем случае с небольшими данными я бы просто загрузил их одним большим глотком для начала, и если есть проблемы со временем загрузки, усложнил бы это оттуда. Усложнение кода с самого начала без явно необходимой причины — это хороший способ загромождать код до такой степени, что он становится совершенно громоздким в обслуживании.
В-третьих, если вы имеете дело с наборами данных масштаба предприятия, это совсем другое дело. Затем вам придется иметь дело с нумерацией страниц, и да, это становится немного сложнее.
С уважением,
DB
03.09.2018
