Я не уверен, полезен ли здесь шаблон ленивой загрузки


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

Кстати, здесь я не спрашиваю о полезности шаблонов ленивой загрузки в целом, а о том, полезен ли он в том виде, в котором он реализован в этой конкретной книге:


1) В любом случае, когда создается объект DLL, выполняется запрос к БД (через DAL), который извлекает данные из различных столбцов и заполняет ими свойства нашего объекта DLL. Так как одно из полей (назовем его "L") может содержать довольно значительный объем текста, автор решил извлекать это поле только при первом чтении этого свойства.


А) В нашей ситуации, что именно мы выиграли, применив шаблон ленивой загрузки? Просто меньше памяти?


B) Но, с другой стороны, разве способ, которым автор реализовал шаблон ленивой загрузки, не заставляет ЦП выполнять больше работы и, следовательно, больше времени для завершения, поскольку, если L извлекается отдельно от других полей, то это потребует от нашего приложения сделать дополнительный вызов Sql Server, чтобы получить «L», в то время как без шаблона ленивой загрузки потребовался бы только один вызов Sql Server, так как мы получили бы все поля сразу?!

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


спасибо


design-patterns asp.net lazy-loading
person SourceC    schedule 18.07.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

Если у вас есть экран (назовем его Customers.aspx), на котором отображается список клиентов (но не столбец CustomerPublicProfile), вам следует попытаться избежать заполнения этого столбца.

Например, если ваша страница Customers.aspx показывает 50 клиентов одновременно, вам не нужно получать CustomerPublicProfilecolumn для каждого клиента. Если пользователь решит перейти к конкретному клиенту, вы должны пойти и получить столбец CustomerPublicProfile.

Что касается B, да, это делает N дополнительных вызовов, где N – это количество клиентов, которых пользователь решил детализировать. Но преимущество в том, что вы сэкономили много дополнительных ненужных накладных расходов, пропустив столбец в первую очередь. В частности, вы избегали получения значений M-N в столбце CustomerPublicProfile, где M — это количество клиентов, которые были получены на странице Customers.aspx с самого начала.

Если в вашем сценарии M имеет значение, близкое к N, то оно того не стоит. Но в ситуации, которую я описал, M обычно намного больше, чем N, так что это имеет смысл.

Сайед Ибрагим Хашими

person Sayed Ibrahim Hashimi    schedule 18.07.2009
comment
Итак, в моей конкретной ситуации шаблон ленивой загрузки экономит мне только немного памяти? - person SourceC; 19.07.2009
comment
Нет, это также снижает нагрузку на БД и пропускную способность от вашего клиента до вашей БД. И это ускорит ваше приложение. - person Sayed Ibrahim Hashimi; 19.07.2009
comment
Извините, что продолжаю тянуть с этим. Но почему это также ускорит (в моем конкретном случае) мое приложение. Как вы сами сказали, ленивая загрузка вызывает N дополнительных вызовов в БД. Возможно, вы ускорите его, избегая получения значений MN (я предполагаю, что «-» представляет минус) столбца CustomerPublicProfile, но, насколько я могу судить, не используя шаблон ленивой загрузки и, следовательно, необходимость извлечения дополнительных значений MN приведет только к увеличению памяти. потребление и немного дополнительного времени, чтобы присвоить значения столбца M-свойствам. Но действительно ли это требует меньше обработки, чем N дополнительных обращений к БД? - person SourceC; 19.07.2009
comment
Хорошо, если ваша страница Customers.aspx показывает 50 клиентов и предполагает, что CustomerPublicProfile составляет около 1 МБ каждый, действительно ли вы хотите, чтобы пользователь ждал, пока 50 МБ не будут извлечены и обслужены? И если средний пользователь изучает только 3 клиентов, вы получаете дополнительные 47 МБ и отправляете их пользователю. 1 МБ может быть избыточным, но идея та же, просто увеличьте количество клиентов с 50 до 500. Также имейте в виду, что это всего лишь 1 пользователь. - person Sayed Ibrahim Hashimi; 20.07.2009
comment
спасибо, приятель. Я очень ценю вашу помощь - person SourceC; 20.07.2009

arrow_upward
2
arrow_downward

Имеет смысл, если объекты DLL можно использовать без поля L (в большинстве случаев). Если это так, ваша программа может работать с доступными данными, ожидая загрузки L. Если L требуется всегда, то шаблон просто увеличивает сложность. Я не думаю, что это значительно замедлит работу, особенно если загрузка L занимает больше времени, чем что-либо еще. Но это всего лишь предположение. Напишите как с ленивой загрузкой, так и без, потом посмотрите, что лучше.

person stribika    schedule 18.07.2009

arrow_upward
1
arrow_downward

Недавно у меня была такая ситуация, когда я хранил большие двоичные объекты в базе данных. Я, конечно, не хотел, чтобы эта загрузка в объект DLL каждый раз, когда он был инициализирован, особенно когда объект был частью коллекции. Так что бывают случаи, когда ленивая загрузка поля имеет смысл. Однако я не думаю, что есть какое-то общее правило, которому вы можете следовать — вы знаете свои данные и то, как к ним будет осуществляться доступ. Если вы считаете, что более эффективно совершить одно обращение к базе данных и использовать немного больше памяти, то вам следует поступить именно так.

person Dan Diplo    schedule 18.07.2009