Не съм сигурен дали моделът за отложено зареждане е полезен тук


В момента чета книга за програмиране на уебсайтове и авторът споменава, че ще кодира DLL обекти, за да използва модел на мързеливо зареждане. Мисля, че концептуално разбирам донякъде модела на мързеливо зареждане, но не съм сигурен дали разбирам полезността му в начина, по който авторът го е внедрил

Между другото – Тук не питам за полезността на моделите за мързеливо зареждане като цяло, а дали е полезно по начина, по който тази конкретна книга го прилага:


1) Така или иначе, когато се създава DLL обект, се изпълнява DB заявка (чрез DAL), която извлича данни от различни колони и с тях попълва свойствата на нашия DLL обект. Тъй като едно от полетата (наречете го "L") може да съдържа доста значително количество текст, авторът реши да извлече това поле само когато това свойство се чете за първи път.


A) В нашата ситуация, какво точно спечелихме чрез прилагане на модел на мързеливо зареждане? Просто по-малко използване на паметта?


B) Но от друга страна, начинът, по който авторът е внедрил модела на мързеливо зареждане, не кара ли процесора да върши повече работа и следователно по-дълго време за завършване, тъй като ако L се извлича отделно от други полета, тогава това ще изисква нашето приложение да направи допълнително извикване на Sql сървър, за да извлече "L", докато без модел на мързеливо зареждане ще е необходимо само едно извикване на Sql сървър, тъй като ще получим всички полета наведнъж?!

Между другото – осъзнавам, че моделът на отложено зареждане може да бъде изключително полезен в ситуации, в които извличането на определена част от данните би изисквало тежки изчисления, но това не е случаят в горния пример


благодаря


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
Не, спестява също напрежението върху DB и честотната лента от вашия клиент до вашата DB. И това ще ускори вашето приложение. - person Sayed Ibrahim Hashimi; 19.07.2009
comment
Съжалявам, че продължавам да се бавя с това. Но защо би ускорило (в моя конкретен случай) моето приложение. Както сам казахте, мързеливото зареждане причинява N допълнителни извиквания към DB. Може би го ускорявате, като избягвате получаването на M-N (предполагам, че '-' представлява минус) стойности на колоната CustomerPublicProfile, но доколкото мога да преценя, неизползването на модел на мързеливо зареждане и по този начин необходимостта от извличане на допълнителни M-N стойности само би довело до повече памет консумация и малко допълнително време за присвояване на стойности на колони на M свойства. Но това наистина ли отнема по-малко обработка от N допълнителни извиквания към DB? - person SourceC; 19.07.2009
comment
Добре, ако вашата страница Customers.aspx показва 50 клиента и приемете, че CustomerPublicProfile е около 1MB всеки, наистина ли искате да накарате потребителя да изчака, докато 50 MB бъдат изтеглени и обслужени? И ако средният потребител се ориентира само към 3 клиента, вие сте изтеглили 47 MB ​​допълнително и сте ги изпратили на потребителя. 1 MB може да е прекалено, но идеята е същата, просто увеличете 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