我不知道延遲加載模式是否是這裏

Question

目前，我正在讀一本書的網站編程和作家有用提到他將編寫DLL對象使用延遲加載模式。我認爲在概念上我有點理解懶加載模式，但我不知道，如果我理解它在作者實現它的方式的有用性

順便說一句 - 這裏我一般不要求延遲加載模式的用處，但無論是在方式有用這個特定書實現它：

1）反正，創建DLL對象時，一個DB查詢經由DAL），其從各列，並與檢索數據執行（它填充我們的DLL對象的屬性。由於其中一個字段（稱爲「L」）可能包含相當多的文本，因此作者決定僅在該屬性第一次被讀取時才檢索該字段。

A）在我們的情況下，究竟爲什麼我們通過應用延遲加載模式獲得什麼？內存使用量更少？

B）但是，在另一方面，不作者的方式實現延遲加載模式引起CPU做更多的工作，因此更長的時間才能完成，因爲如果L被從其他字段分別檢索，那麼這將需要我們的應用程序額外調用Sql Server以檢索「L」，而沒有延遲加載模式，則只需要對Sql Server進行一次調用，因爲我們將一次獲得所有字段？！

順便說一句 - 我知道延遲加載模式可以是在其中檢索數據的特定部分將需要繁重的計算的情況下非常有利的，但是這不是在上面的例子

感謝名單

的情況下

Answer 1

我認爲這適用於正確的列時非常有用。例如，假設您在數據庫中有一個表格Customers，並且在該表格中您有一列CustomerPublicProfile，這是一個可能非常大的文本列。

如果您有一個顯示客戶列表（但不包括CustomerPublicProfile列）的屏幕（我們稱之爲Customers.aspx），那麼您應該儘量避免填充該列。

例如，如果您的Customers.aspx頁面一次顯示50個客戶，則不必爲每個客戶獲取CustomerPublicProfilecolumn。如果用戶決定深入瞭解特定客戶，那麼您可以去獲取CustomerPublicProfile列。

關於B，是的，這確實讓ň額外要求，其中ñ是用戶決定深入到客戶的數量。但優點是您首先在跳過列時節省了大量額外的不需要的開銷。具體而言，您可以避免在CustomerPublicProfile列中獲得M-N值，其中M是在Customers.aspx頁面上檢索的客戶數量。

如果在你的場景M有一個值接近N那麼它是不值得的。但在我描述的情況下M通常比N大得多，因此它是有意義的。

賽義德·易卜拉欣·哈希米

Answer 2

如果DLL對象可以在沒有L字段的情況下使用（大部分時間），這是有道理的。如果是這種情況，您的程序可以在等待L加載時使用可用數據。如果總是需要L，那麼該模式會增加複雜性。我認爲這不會顯着減慢速度，特別是如果加載L需要更多時間。但這只是一個猜測。寫延遲加載和沒有然後看哪個更好。

Answer 3

我有過這樣最近我在那裏在數據庫中存儲大型二進制對象的情況。我當然不希望每次初始化時都將這些加載到DLL對象中，特別是當對象是集合的一部分時。所以有時候懶加載一個字段是有道理的。但是，我不認爲你可以遵循任何一般規則 - 你知道你的數據以及它將如何被訪問。如果您認爲一次訪問數據庫並使用更多內存會更有效率，那麼您應該這樣做。