複雜共享/靜態成員的最佳實踐

我接管了一個ASP.NET應用程序，並在應用程序的幾個類中找到了它。程序員在定義了幾個共享/靜態變量之前，在整個應用程序中充當「複雜枚舉」。作爲一個相當新的程序員，它看起來不像最佳實踐。複雜共享/靜態成員的最佳實踐

下面是一個例子：

Public Shared SecureCommentsWrite As New Task("Secure Comments Write") 
Public Shared SecureCommentsRead As New Task("Secure Comments Read") 
Public Shared EditEmergencyContact As New Task("Edit Emergency Contact") 
Public Shared DisplayPersonalReferences As New Task("Display Personal References") 
Public Shared EditPersonalReferences As New Task("Edit Personal References")

構造函數的描述，然後從數據庫加載使用存儲過程的ID密鑰（數據庫是SQL服務器。）這似乎是因爲我們是個好主意將此應用程序部署到多個數據庫，並希望確保我們加載該數據庫中的ID密鑰，以防其發生更改。但是，由於在應用程序中確實存在數百個，所以第一次加載需要一段時間。

這被認爲是最好的做法，如果沒有，什麼被認爲是這樣的情況最好的做法？

來源

2011-09-07 Spencer Schneidenbach

擁有代表常量值的靜態字段列表並不存在固有的錯誤;正如您所指出的那樣，它基本上與枚舉相同，而且微軟自己在一些自己的庫中完成了它。也就是說，如果初始化這些字段導致明顯的減速（並且因爲它們每次都觸及數據庫，這並不是真正的驚喜），可以使用一些技巧來提高加載時間。一個顯而易見的解決方案是採用延遲加載 - 換句話說，直到你絕對必須的時候纔打到數據庫！這基本上分攤了在數據庫的整個生命週期中觸發數據庫以初始化這些字段的成本，從而爲您提供更快的啓動速度，以換取其他地方稍微較慢的性能。

當然，如果你不得不一次延遲加載100或1000個，這可能不是理想的解決方案;在這種情況下，你只是將巨大的延遲轉移，而不是將其分解。

另一個想法是提高負責檢索這些ID的SQL的效率。您可能會編寫一個Initialize()方法，該方法執行單個查詢來一次性提取所需的所有ID，而不是在100個不同的查詢中執行。這幾乎肯定會更快。

來源

2011-09-07 19:06:00

對我來說這是一個可怕的做法，如果你告訴我，每個上面和任務建構一個分開的存儲過程，這些行被稱爲（即使相同的存儲）。

這種情況下的最佳做法是重構，對該存儲過程進行單一調用並修改它以返回所有ID和名稱，然後使用一個TaskManager或TaskLoader（不管）類來映射存儲的結果並創建所有這些元素沒有進一步的數據庫參與。

在這些情況下

注意到一個SqlDataReader很可能會比一個DataSet更好，因爲你只需要只進，讀取到的數據只有快速訪問。

，現在一切都從我身邊;-)

來源

2011-09-07 19:04:50

你可能想在這裏一個工廠類（TaskFactory？）。

應該加載（一次）表示的Task項的整個列表的DataTable或數據集。這可以通過構造函數來完成，或者在執行第一個實例請求時[懶洋洋地]完成。

每次而不是擊中分貝，工廠的CreateInstance()方法則應該諮詢它所需要的預加載數據。

來源

2011-09-07 19:05:34

這不是一個很好的做法，進行數據庫查詢/在對象的構造函數的存儲過程，或任何其他可能耗時的操作。如果在初始化Task對象時出現問題，由於它被聲明爲靜態/共享成員，它可能會拋出TypeInitializationException，並且您的應用程序將變得不可用。

我會將這些成員視爲某種應用程序配置。在Application_Start期間執行一個存儲過程，該過程將一次性（而不是逐個）引入所有數據，並創建配置對象。

來源

2011-09-07 19:05:35 Vasea

複雜共享/靜態成員的最佳實踐

回答

相關問題