浅谈三层架构中的实体类(C#)
???????? 本文所指的實體類僅限于三層中的實體類，即數據庫表的映射。
?
一、為什么要用實體類？
?
???????? |? 使程序簡潔易懂，便于維護。
???????? |? 暗合接口不變原則。
???????? |? 體現面向對象思想。
?
????????舉例說明：
?
???????? 不用實體類的三層
????????假如程序有所變動，需要增加一個參數，學生年齡
????????用實體類的三層
????????同樣增加一個參數，學生年齡
?
???????? 很明顯的看出，用實體類之后，代碼明顯變得簡潔，面向對象封裝思想。
???????? 最重要的是，如果將來有所改動，只需要改動實體類，方法間調用接口，完全不需要變動，大大減少了程序修改量，迎合了面向對象中接口不變的思想。
???????? 甚至在程序設計時，就把將來可能需要的屬性預先放在實體類中，這樣以后變動時，連實體類都不用變動。
?
二、實體類缺點在哪（僅是個人觀點）？
?
???????? 雖然實體類有明顯的優勢，但親身使用時會發現一個明顯的問題：代碼可讀性貌似降低了。
???????? 上邊例子中體現的不是很明顯。再來一個簡單的例子。
???????? 假如有一個方法(沒有用實體類)：
???????? selectByPartDate(DateTime startDate,DateTime endDate){}
???????? 此方法用來查詢某段時間內的記錄，兩個參數：一個是起始時間，一個是結束時間。
???????? 雖然沒有用實體類，可是讓人看起來很舒服，一看就知道要干什么。
???????? 用了實體類后(假設實體類名是LoginLog)：
???????? selectByPartDate(LoginLog startDate, LoginLog endDate){}
???????? 讓人看了不知所措，難以理解到底想做什么。
???????? 當然，這種不知所措可以通過兩個途徑解決：
?????? ? |? 良好的命名規范，達到 “見名知意”。
???????? |? 良好的文檔說明或者代碼注釋。
?
???????? 在這，引出一個問題：三層中，所有的方法都要用實體類傳遞參數嗎？
???????? 最明顯的就是上邊selectByPartDate例子，還有諸如：deleteByID(longid){}這樣的方法。真的有必要傳遞實體類嗎？
???????? 實體類的確是容易擴展、修改，可這不違反設計原則嗎？
???????? 設計原則是：盡量避免對原有代碼的修改，而是通過增加代碼的方式去解決。
???????? 諸如selectByPartDate、deleteByID這樣的方法，目的已經很明確了：查詢某段時間內的記錄、根據id刪除記錄。換句話說，這就是它們存在的意義。
???????? 程序再怎么擴展，能涉及到這類方法？假如真的把這類方法擴展了，那么它們完全失去了自己的意義！
???????? deleteByID就是根據id刪除，擴展了，就不是根據id刪除了！這時候你可以再添加一個新的方法，何必和deleteByID過不去呢？
???????? 對于參數極少，目的明確的方法，個人認為沒必要用實體類。
???????? 這只是我的個人看法，歡迎高人指點！
????????
三、源自實體類的靈感！
?
???????? 三層中，大家都知道U層的邏輯應該盡量少，盡可能的轉移到B層。
???????? 但是實際應用中如何轉移卻是個問題。
???????? 就拿刪除記錄來說，U層調用B層，B層調用D層，由D層返回布爾值，來說明刪除是否成功。
???????? 這樣傳遞參數，最終U層得到的是一個布爾值，真或假，攜帶的信息太少了，只能反饋給用戶成功或者失敗(同時多了一次判斷邏輯)，而為什么失敗，就無從得知了。
???????? 現實應用中有很多這樣的例子，有時候為了給出用戶更詳細的提示，不惜把B層分的很細，然后在界面大量的調用B層方法，加上大量的判斷，才能給用戶一個完整的提示。
???????? 這樣的情形顯然不是我們想要的？那么怎么解決呢？
???????? 造成這種情況的根本原因就是布爾型返回值攜帶的信息太少，哪個類型多？當然是字符串型！
???????? 在D層，可以返回布爾值，讓B層判斷使用。但是B層返回給U層的值，強烈反對是布爾型的！
???????? 按照這個思路，在B層使用復雜的邏輯，然后把執行結果以字符串的形式的返回。這樣一來，U層無需任何判斷，直接把B層返回的字符串顯示出來就行了！
???????? 舉個例子(B層的一個方法)：
[csharp] view plaincopyprint????????? 很明顯的看出，一切判斷都是在B層完成的，然后把結果以字符串形式返回給U層，簡潔明了，U層不需要任何邏輯，直接show就行了！
???????? 這樣看上去很好，但是字符串還是比較讓人不舒服，既然是面向對象，為何不返回一個實體類呢？
???????? 我們可以定義一個實體類，名字就叫LayerParameter。給這個實體類加一個字符串型的resultString屬性，就把剛剛的字符串返回值封裝進來了。就用這個實體類作為B層給U層的返回值。
???????? 這樣做簡直完美！
???????? 有經驗的朋友可能遇到過刷新界面的問題，也就是U層需要根據實際情況來刷新界面數據，在B/S結構中尤其明顯。有了實體類做返回值，就啥都不怕了！不就是刷新嗎？在LayerParameter實體類中加一個布爾型屬性refresh，U層調用B層后，show一下返回值(LayerParameter類實例)的resultString屬性，把執行信息告訴用戶，然后再判斷一下refresh屬性，決定是否刷新界面數據(U層一點邏輯都沒有是不可能的！)，此時B層給U層的返回值，仍然是LayerParameter，接口無需任何改動。
???????? 以上僅僅是個人想法，希望大牛指點！
?
???????? 最后，申明一點：
???????? 一切的一切還是要以項目實踐為基礎，經驗才是王道，否則一切討論都是空穴來風！
總結
以上是生活随笔為你收集整理的浅谈三层架构中的实体类(C#)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 为什么需要实体类
- 下一篇： 用MyEclipse自动生成hibern