使用查找表時保持代碼可讀性 - 性能與可維護性

使用GUID主鍵在可能的事件類型存儲在數據庫的查找表中的審覈系統上工作。由於各種原因，它們必須保存在數據庫中，而不是存儲在枚舉或類似的東西中。使用查找表時保持代碼可讀性 - 性能與可維護性

目前，中等的任務，我的代碼是充滿了這個樣子位：

if (currentLp.PercentageShare != lp.PercentageShare) 
{ 
    //percentage change audit 
    DiaryEvent de = RepositoryHelper.AuditEvent(lp.CilCase_Id, new Guid("56900C62-3164-4111-BAEC-4F102FEF5813")); 
    _cilUpdateContext.DiaryEvents.Add(de); 
}

的問題，這是顯而易見的 - 我知道，那個特定的Guid映射到一種被稱爲「所佔的百分比更改「，但其他人進入代碼不會，除了我的一次性評論。

我可以想出解決這個問題的兩個辦法。

首先是從代碼中使用描述字段查詢數據庫以獲取Guid，但這是一個很大的性能問題，因爲這將會發生很多。

第二個是在類中設置一個Guid/String Dictionary，它映射到查找表中的值，並使用它來獲取Guids。但這是一個很大的可維護性問題，因爲它們的類型列表偶爾會發生變化，系統中的任何人都需要記住確保兩者保持同步。

哪個更小？還是有另一種解決方案？

來源

2013-12-11 Matt Thrower

在整個應用程序中有一個簡單的'static const'字段有什麼問題？無論如何，GUID是不變的，不是嗎？ –

爲什麼GUID鍵？使用int或long鍵，您可以使用知名事件類型的枚舉，例如「PercentageShareChanged」。 – Joe

問題不在於GUID鍵，而是數據必須位於數據庫中。即使我將它們更改爲整數鍵（我可以），該列表仍需要維護在兩個地方。 –

爲什麼你不結合這兩種方法？

在啓動時，讀取數據庫的名稱/的Guid對到內存表
然後，只需看看他們有
如果需要的話，執行將重新讀取數據庫表中的任務信號，所以你可以做在線更新。

但是更新（=意義的改變）應該是可以避免的。嘿，但這真是一個GUID，請it's已經獨一無二的，所以只有當你添加新的審計事件，就必須尋找到數據庫再次：

或替代的信號，只是看在DB如果在內存表中找不到Guid，則還需要一次。

它結合了速度和Db靈活性。

BR Florian

來源

2013-12-11 14:36:31 flohack

謝謝。我自己沒有想到這件事，我感到很蠢！ –

你不客氣。有時候你需要從森林裏的森林退後，就像我們在奧地利所說的那樣;） – flohack

使用查找表時保持代碼可讀性 - 性能與可維護性

回答

相關問題