個人BO之強類型

個人BO
1-個人BO之強類型
2-個人BO之數據保護
3-個人BO之狀態控制
4-個人BO之導航屬性

弱類型的缺點

有些程序員對類型比較隨意，從前端傳來的數據，無論應該是什麼類型，都以String接收。而後在什麼地方轉成應該有的類型則要「看心情」，在Controller, Service, DA都有，甚至有從頭至尾都不轉爲正確類型的。這裏把一切都用String表示稱爲「弱類型」，相應地該是什麼就是什麼類型稱爲「強類型」。好比Service方法的參數清一色String型的，其中的參數的位置傳錯了也發現不了。Long,Date型也是按String在各層之間傳送，若在DA層沒有一個強有力的組件保障，很容易就被黑客SQL注入。有些中途要做運算，不得已轉爲強類型運算，而後由於下一級是弱類型，又轉爲弱類型繼續傳遞。許多地方明明能夠判斷兩個值是否相等，卻由於類型不一樣須要先做轉化，轉化的過程又由於值是null而出錯，恰恰出錯方面又沒處理好，真是接連挖了幾個坑等着人跳。

圖：該是什麼就是什麼

正確的作法是用最正確的類型表示和傳送每個數據。至少在BO這一層，要徹底強類型。

枚舉類型

在DTO和數據庫中，多是String，多是Integer，但對於BO來說，它就只應該是枚舉類型。這樣無疑對業務處理是最方便的。

日期時間類型

先後端交互時，出於方便調試的目的，咱們採用字符串來表示，具體格式是yyyy-MM-dd HH:mm:ss。 在DTO中體現爲String型，而在BO中則爲Date類型。

Java的Date出現得早，受普遍各類組件的支持，但運算不方便，LocalDateTime運算方便，但出現得晚，不受普遍支持。用Date仍是LocalDateTime都算強類型。原本應該採納運算方便的LocalDateTime，但考慮到須要運算的可能性小，不須要運算的可能性大，若採用LocalDateTime，就會增長沒必要的正反兩次與Date轉化。最終決定兩種類型同時支持，內部關聯同一個數值。在須要運算時，讀寫LocalDateTime型的屬性時自動轉化，在不須要運算時讀寫Date型的屬性則不會產生兩次額外的轉換。兩種類型之間的轉換由BO內部自動完成，外部使用時哪一種類型方便就用哪一種，十分方便。

強類型的優勢：

1. 防止SQL注入
2. 方便運算
3. 正確的取值範圍

以前個人一篇文章推薦使用的7種基本數據類型講到這方面。在數據庫提供的不少種類型支持的狀況下，咱們也只挑戰少數幾種類型使用。在BO層則是以最貼切的類型來使用，並不侷限於7種。好比BO中使用的枚舉型，在數據庫中每每表現爲String型或Integer型。二者並不矛盾。

系列導航

1-個人BO之強類型
2-個人BO之數據保護
3-個人BO之狀態控制
4-個人BO之導航屬性