三层开发中容易犯的错误
三層開發中容易犯的錯誤
前記：
相信大家對三層開發都已經耳熟能詳，可是我卻發現新公司的既有代碼中有一些違背分層開發思想的東西，現在與大家分享這些錯誤，我們共勉之。
如果有人覺得對三層開發拿捏得不是太準，請參照李天平的文章：分層開發思想與小籠包,這篇文章用隱喻說明分層開發，是非常好的一篇文章。
正文：
1．界面層參與非界面邏輯，搶業務邏輯層的飯碗
什么是界面邏輯：
界面層應該有的邏輯就是顯示的邏輯，例如根據邏輯結果顯示某一個Panel不顯示另外一個Panel，或者有一個數據集應該在界面上怎么呈現，這是界面層的邏輯
例子場景：
用戶登錄時首先驗證用戶輸入的用戶名是否有效，如果用戶名有效，然后再驗證用戶輸入的密碼是否和用戶名匹配，如果匹配則表示用戶可以登錄，增加用戶的登錄次數，然后將用戶的信息寫入Session中；否則返回錯誤。在這個過程中除了將用戶信息寫入Session這一步屬于界面邏輯以外其他的操作都應該放在業務邏輯層。
錯誤代碼示例：
private?void?buttonLogin_Click(object?sender,?EventArgs?ev)????????{
????????????string?userName?=?textBoxUserName.Text;
????????????string?password?=?textPassword.Text;
????????????if?(Business.Account.Exists(userName))
????????????{
????????????????bool?success?=?Business.Account.Login(userName,?password);
????????????????if?(success)
????????????????{
????????????????????Business.Account.AddLoginTime(userName);
????????????????????Session["user"]?=?new?User(userName,?password);
????????????????????Redirect("/");
????????????????}
????????????????else
????????????????{
????????????????????this.labelMessage.Text?=?"登錄失敗。";
????????????????}
????????????}
????????????else
????????????{
????????????????this.lableMessage.Text?=?"用戶名不存在。";
????????????}
????????}
?
分析：在上面的代碼中一個UI層的一個事件中調用了三次rules層的方法：
Business.Account.Exists(userName)
Business.Account.Login(userName, password)
Business.Account.AddLoginTime(userName);
還附加有條件判斷，這種方法在執行效果上面是沒有什么錯誤的，可是卻造成了邏輯前移；本來應該在邏輯層執行的判斷放在了界面層，是不合適的。
2．數據訪問層參與了大量的業務邏輯
這種現象經常出現在大量使用存儲過程的系統中，將一大堆邏輯統統放在一個存儲過程中實現了，乍一看可能很有效率，其實造成了系統結構的失調，給維護帶來困難，數據訪問層甚者數據庫要搶邏輯層的飯碗了。
還以用戶登錄為例：
下面是業務邏輯層的登錄方法：
?
//業務邏輯層的登錄方法????????public?int?Login(string?userName,?string?password)?
????????{
????????????return?DataAccess.UserAccount.Login(userName,?password);
????????}
?
下面是數據層的登錄方法：
?
//數據訪問層的登錄方法????????public?int?Login(string?userName,?string?password)
????????{?
????????????SqlParameter[]?parameters?=?new?SqlParameter[]{
????????????????//?
????????????};
????????????return?SqlHelper.ExecuteProcedure("Login",parameters);
????????}
?
下面是登錄的存儲過程：
?
CREATE?PROC?Login????????????@userName?varchar(20),
????????????@password?varchar(20)
?????????AS?
????????????IF?NOT?EXISTS(SELECT?*?FROM?UserAccount?WHERE?UserName?=?@userName)
????????????????RETURN?-1
????????????IF?NOT?EXISTS(SELECT?*?FROM?UserAccount?WHERE?UserName?=?@userName?AND?password?=?@password)
????????????????RETURN?1
?????????
????????????UPDATE?UserAccount
????????????SET?LoginTimes?=?LoginTimes?+?1
????????????WHERE?UserName?=?@userName
?????????
????????????RETURN?0
?
分析：從上面三段代碼中我們可以很顯然得看到登錄的業務邏輯已經全部被后移到了數據庫的存儲過程中。這樣使用的三層結構就失去了意義，邏輯層名存實亡了；而數據庫的壓力會越來越大；我們修改業務邏輯的時候不是到邏輯層修改，而是要到數據庫中去修改了。
3．將界面層上的數據組件（如SqlDataSource）作為參數傳遞到業務邏輯層去賦值
這樣做的壞處很明顯，本來是界面層依賴于業務邏輯層的，現在業務邏輯層反過來去依賴界面層的類，需要邏輯層引用System.Web命名空間，顯然是錯誤的。
4．為了省事兒，不是直接將參數傳遞到業務邏輯層，而是通過HttpContext直接獲得界面層應該傳遞的參數
例子：在系統設計的初期沒有記錄用戶登錄的IP地址，而到了后期發現了這個問題，要求紀錄用戶IP了，為了不修改業務邏輯層方法的定義，也不用修改界面層的調用方法，于是便寫出了下面的代碼：
public?int?Login(string?userName,?string?password)????????{
????????????string?userIP?=?System.Web.HttpContext.Current.Request.UserHostAddress;
????????????//follow?is?login?steps
????????}
?
這一點犯的錯誤和3中的錯誤相同，導致層之間形成了依賴環。
5．將事務處理放在數據訪問層來做
事務處理應該放在業務邏輯層處理，原因是
1）事務的劃分是根據業務邏輯來定義的，通常一個事務就代表完成了一個完整的邏輯操作；
2）一個業務邏輯可能有幾個數據操作，修改幾個表中的數據，而通常數據層的類的劃分是根據數據庫表來劃分的，如果把事務處理放在數據訪問層，那么業務層的方法需要調用兩個以上的數據層方法時，就會出現執行兩個事務的情況，顯然這是不合理的。
總結：
1．在三層結構的劃分中我們應該使三層各負其責，誰也不能越權，誰也不能懶惰，通常情況下，邏輯層應該在滿足各負其責的條件下，盡可能的厚。
2．三層結構中的依賴關系很明確，界面層依賴于邏輯層，邏輯層依賴于數據訪問層，不能互相依賴，而形成依賴環。
轉載于:https://www.cnblogs.com/smallfa/archive/2007/07/18/822420.html
總結
以上是生活随笔為你收集整理的三层开发中容易犯的错误的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： XHTML和HTMl区别
- 下一篇： 【玩聚】OneJoo中国的第一个meme