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

Question

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

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

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

A) Что именно мы получили в нашей ситуации, применив ленивую схему загрузки? Просто меньше использования памяти?

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

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

1032 * спасибо *

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

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

Сказал Ибрагим Хашими