您當前位置：首頁 > 服務器 > 巧妙傳值，為隊友減負

巧妙傳值，為隊友減負

來源：程序員人生發布時間：2015-01-10 08:37:26 閱讀次數：2950次

不論是采取7層，或是沿用3層，層與層之間的工作劃分都有很強的次序。既然劃分好了層級，規定好了各層各自的任務，那就去尊重，照章實現就行了。各層不但要實行好本身的職責，能在本身職責的基礎上，再發放些福利，那不但程序做得Beautiful，合作也會Beautiful！

直面問題。舉例說明1下：

在“機房收費系統”的上機業務實現中，界面層（UI層）接收用戶輸入的上機所需的必要信息，封裝成實體（Model），傳給業務層（BLL層）。業務層在處理的進程中，需要做以下這些判斷：

①A=“基本數據是不是設定”

②B=“用戶是不是存在”

③C=“卡是不是可用”

④D=“余額是不是充足”

⑤E=“是不是已在線” 。

從上面的5個判斷，看出，每個都只需返回1個Boolean，而且每個Boolean都是獨立的“True”或“False”。在不滿足時，為了能將明確的信息回饋給用戶，明確問題，以方便用戶的調劑，最快地為用戶提供實現。1次只能調用1個，做1個判斷，有1個返回值。這個判斷在BLL層進行過1遍，等傳給UI層又得對返回值進行再次判斷，才能得出結果。如果就這么來，那末UI完成的工作跟BLL所做處理相差不大，還徒增進程的1次調用和判斷。這在任何“懶”的程序猿眼前，都是難以忍耐滴。

上面的這5條判斷，都必須去判斷1遍，全部滿足后，“上機”才能走通。所以關于對它們的判斷誰先誰后，在全部滿足（多數）的情況下是沒有差別的，所以先不斟酌。

在BLL層將這些判斷進行查詢和處理，并集中判斷。

由于上機需要返回“上下機實體”mainEntity。需要為mainEntity添加1個屬性Message。在每次判斷后，根據判斷的結果，選擇性地為實體賦值。

Dim enMain As New mainEntity If A = True Then If B = True Then If C = True Then If D = True Then If E = True Then '檢查全部通過，上機成功！ enMain.Message = Nothing Else enMain.Message = "此卡已在線，不能重復上機！" End If Else enMain.Message = "余額不足，請到管理員處充值后上機！" End If Else enMain.Message = "此卡已注銷，拿上相干證件，請聯系管理員開啟！" End If Else enMain.Message = "用戶不存在，請檢查后，重新輸入！" End If Else enMain.Message = "基本數據未設定，暫不能進行上機操作，請聯系管理員！" End If

在UI層，只需要做1個簡單判斷便可：

Dim enMain As New mainEntity If IsNothing(enMain.Message) Then '上機成功！通知用戶。并將用戶登錄信息顯示在界面上。 MsgBox("登錄成功！", MsgBoxStyle.Information, "提示！") txtCardID.text = enMain.CardID txtUpTime.text = enMain.Uptime '……為實體賦值 Else '登錄失敗！將具體信息回饋給用戶。 MsgBox(enMain.Message, MsgBoxStyle.Information, "提示！") End If

以上有5個if else 嵌套，看起來比較夸大，但業務邏輯簡單，比較清晰，不會給程序的運行和理解帶來負擔，所以是可行的。

避免使用過量嵌套語句可以使用設計模式進行改進，可用裝潢模式進行。

裝潢模式：objec = judgeFunction(objec)

B =judgeFunction(A)

C =judgeFunction(B)

D =judgeFunction(C)

E =judgeFunction(D)

將裝潢的終究結果E返回便可。

這類方法，目前來講，我所能想到的辦法是每裝潢1次就得為實體多添加1個屬性（不是為屬性賦值）。固然，判斷次數是有限、少許、可統計的，裝潢次數也是有限的。設計時多添加幾個屬性也無太大問題。

系統優化：如果深加分析，可以斟酌，將易產生“不滿足”的判斷放在前面，如果不滿足，立即返回，不用進行后面的其他判斷，固然會有提升性能。

通過這類方式，將層與層之間的數據傳輸進行封裝。這樣，不同層之間的開發人員，就不需要過量地知道其他層的細致的問題，從而減輕了負擔。開發變得更加傻瓜試，這樣，程序的自動化更具可操作性。

只在情勢上進行劃分，在實質上，不但沒有帶來便利，反而變得繁瑣。那只會被嗤之以鼻，遭受唾棄。設計模式的使用早期也是這類感覺，隨著使用頻繁，遇到繁瑣問題進行使用，漸漸感覺到分成和設計模式的妙處。