現在的開發架構一般都是三層或四層架構，較下的層總是提供介面或方法給上層呼叫，這時就遇到乙個問題了：呼叫下層介面或方法的時候，傳入的引數需要怎樣驗證正確性呢？如果兩個層次之間是屬於同乙個專案或是同乙個公司的專案的話可能還可以檢視一下源**，看一下下層的實現方法是否有驗證引數的正確性，但如果是使用其它的類庫，我們無法看到源**的時候咋辦？甚至有時候在同乙個公司，同乙個專案中，下層介面方法的編寫者也不知道該不該在每個方法裡驗證引數是否正確，是否不為
null
（這個最常見了）。
這個時候，大家都應該遵守一種業務的約定，很多問題便能迎刃而解了。下面舉兩個小例子：
action
service
page listdata()
在上圖中
，action
呼叫service
中的乙個返回型別為
page
的listdata
的方法，
然後再作小許的加工就可以將
page
中的資料放到頁面中顯示了。在這種場景下，頁面對
page
中有沒有資料其實是不關心的，
action
並不會檢驗（也沒有必要）
page
裡是否有資料，只要
page
裡的資料不為
null
就可以了（要清楚沒有資料跟
null
的區別），因此，
service
的listdata
介面返回的
page
一定不能為
null
。如果上圖中的
listdata
方法改為返回型別為
mapuser
的getuser方法，
則又有另一種說法了。
getuser
方法的使用場景大部份是必須要查出真實資料的物件的，當
action
傳入的引數在
service
裡查不到資料的話，
service
絕不能返回乙個不帶任何資料的
mapuser
物件，而是返回
null
就可以了，讓
action
自己作判斷，然後做應該做的事。
建築和軟體中模式之異同
csdn的透明特別推崇 建築的永恆之道 認為從中探尋到軟體的永恆之道,並就 設計模式 寫了專門文章 探 尋軟體的永恆之道 其中很多觀點我看了很受啟發,以前我也將 設計模式 看成乙個簡單的解決方案,沒有從一種高度來看待 設計模式 在軟體中地位,下面是我自己的一些想法 建築和軟體某些地方是可以來比喻的 ...
建築和軟體中模式之異同
csdn的透明特別推崇 建築的永恆之道 認為從中探尋到軟體的永恆之道,並就 設計模式 寫了專門文章 探尋軟體的永恆之道 其中很多觀點我看了很受啟發,以前我也將 設計模式 看成乙個簡單的解決方案,沒有從一種高度來看待 設計模式 在軟體中地位,下面是我自己的一些想法 建築和軟體某些地方是可以來比喻的 特...
建築和軟體中模式之異同
csdn的透明特別推崇 建築的永恆之道 認為從中探尋到軟體的永恆之道,並就 設計模式 寫了專門文章 探尋軟體的永恆之道 其中很多觀點我看了很受啟發,以前我也將 設計模式 看成乙個簡單的解決方案,沒有從一種高度來看待 設計模式 在軟體中地位,下面是我自己的一些想法 建築和軟體某些地方是可以來比喻的 特...