別再用數據庫生成的ID了
本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。
很多人都曾經至少有一次利用數據庫為應用程序生成ID的經歷。但事實上，這種做法在開發應用程序過程中是大錯特錯，使用自動遞增的整數ID會則錯得更加離譜。
是時候徹底擺脫這個不良行為了。
可以肯定的是，這會與你在101 college平臺關系數據課上學到的知識，以及你在youtube平臺上觀看的無數個如何用TerribleIds ()創建表格的視頻形成鮮明對比。
用數據庫生成應用ID會造成什么問題?
首先，最大的問題是你把應用程序中一個極其重要的部分授權給第三方軟件，在授權第三方責任時，你已經失去了對這個應用程序的掌控權。
其次，在設計實體類時，你可能會使用不恰當的方法，因為你想讓它與一個永久框架更兼容，比如說C# .NET中的實體框架。初級程序員犯的最嚴重的一個錯誤就是使用public Id setter方法來設置ID。
第三，你突然要依靠第三方來給實體提供ID，這會把原本不復雜的單元測試變得復雜。假設你已經發現使用public ID setter本質上是一個嚴重的錯誤，而你又不想通過調用代碼來設置ID。創建的類看起來會如下所示：
你選擇的ORM仍然可以通過反射來設置id字段。要知道，有反射存在就沒有什么是真正安全的。
但該如何對此進行單元測試?實例化時將id字段設置為0。實例化多個TerribleBook會出現身份沖突情況，因為現在不止一個TerribleBook具有相同的ID，即便他們代表兩個不同的實體。
如何生成更合適的ID并追回授權?
方法其實非常簡單，看下面的代碼：
不是人人都能注意到TerribleBook到FixedBook之間的轉變，所以請認真閱讀這段代碼。
首先，ID由整數變成字符串，這樣可以更好地實現伸縮性，但一定要限制數據庫中字段的長度。永遠不要對已知長度的字段使用 VARCHAR(MAX)——它會占用內存。
然后將構造函數設為私有，并使用靜態工廠方法實例化新對象。這樣可以從調用者中抽象出實例化邏輯，甚至為我們提供了使用多態的機會——我們可能想返回某個Null對象而不是拋出。
注意，雖仍然把id當作構造函數參數，但是ID的生成和提供是由我們來決定的(在第18行)，而不是數據庫。
Guid.NewGuid()。ToString("D")只能確保獲得連字符格式的GUID。筆者喜歡用GUID，但是你可以自由構建自己的ID，無論哪種ID都可以滿足你的業務和應用程序需求。
現在，我們拿回了控制權。
圖源：unsplash
或許你會說：“但是實體將不再按順序存儲!”這完全正確，但沒什么好擔心的。初級開發人員喜歡有序存儲實體，即便這通常對業務不會產生任何影響。如果確實需要按順序存儲內容，只需創建一個日期時間列即可。
