0
在我的工作中，我主要從事有很多數據庫代碼的業務應用程序。我通常不會編寫數字化的科學邏輯。包裝類型除了性能還有什麼缺點嗎？
這讓我想知道 - 在我的實體類中總是使用包裝類型是否是個好主意？我發現自己經常把原語轉換成包裝。相反，我想不出一個沒有原始性的情況。
如果我將我的實體中的字段聲明爲wrappers，那麼從db讀取的數據將自動映射到我的持久層上，從而爲我節省了手動創建它們的麻煩。
有些事情只能通過經驗來實現，因此我問你們有沒有人試過這種方法？它有什麼問題嗎？
我不關心性能，但是從良好的實踐/體系結構的角度來看這個問題。
由於cpu和內存不是我關心的問題，並且db值顯然可以爲空，所以我想這是對所有包裝方法的點頭。是？ –
如果它可以是'null'，則使用包裝器可能是更好的選擇。我更喜歡在可能的情況下使用原語，但在這種情況下不會。 –
順便說一句，關於較長名字的觀點似乎不重要，除了編寫「Integer」而不是「int」所需的時間可能會比內存差異的開銷高出1000倍。但是，編寫混淆代碼的代價通常要高得多，所以儘可能簡單明瞭。 –