對於B/S都是MVC好不好 不多說了，反正大家都這么用
這里簡單說下C/S
首先常用的幾種：
- 模仿B/S的MVC 也有人稱之為 MVP
- 還有MVVM這種真心覺得夠夠的了，當然也有其優勢所在，這里不討論孰優孰劣
- 。。。好吧剛吃過早飯腦子不想動，想不起來了，歡迎大神補充
分層的目的是為了實現高內聚低耦合，而我嘛就是想讓代碼好看一點……
如何分層才能夠比較快速地開發呢？好吧似乎兩者根本沒有任何關系
沒有嗎？有嗎？
可以說沒有，但實際上應該是多多少少有點的(咋感覺像莫須有的趕腳)
以我的MyRapid為例，說下我的分層
首先是WCF實現C/S分離，有人把C/S分開也算一種分層（呵呵）
這里要涉及到分層了，有的人在服務端分層，WCF作為Control 下面可能有BLL， BLL再下面還有一個DAL，這種情況個人認為就會影響開發速度了，團隊里面多個人同時在修改服務層，沒經歷過真心不知道有多痛苦，小心不能再小心了，每次修改一定要先更新到最新的，還要吆喝一下我改了哪個，有修改過的抓緊上傳，要不該沖突了
所以說分層還是和開發效率有關系的……
我的解決方案是WCF寫死，不動，WCF只有2個方法，讀、寫，最近增加了一個執行，其實用讀也可以實現，讀就是執行Sql並且返回數據表，寫就是執行但是不返回(也可以返回int)，執行就是執行后不管了，有點異步的意思(整體感覺有點SqlHelper再次封裝的意思)
那么需要考慮的就是讀寫的參數問題了
這個時候先來一個前端UI，下面跟一個BLL，在下面一個DAL，DAL調用的不再是SqlHelper而是WCF(WCF數據源是不是就是這個思路？沒深入了解，嘿嘿)
這樣在一定程度上解決了團隊開發的版本沖突問題，當然也存在了業務邏輯暴露的危險，必定BLL、DAL都放在了 客戶端，在一定程度上犧牲了安全性，至於解決方案以后再說
再來說下DAL的優化，BLL個人沒有發現優化的可能，倒是發現不少毫無疑義的轉接，前面調用一個GET() 到了BLL BLL啥也不干直接調DAL的GET() 也有優化空間，不過都是代碼生成器，實際上沒什么優化價值
直接說DAL的優化，DAL說白了就是傳Sql語句的，現在用EF的話都不怎么需要了，我的框架沒有用EF所以還是要說下(關於EF的優缺點歡迎百度，不多說了)
首先Sql的參數，有人喜歡拼接字符串，我是強烈反對的，參數化查詢的優點可以直接百度
如果使用參數化查詢這里涉及到一個空參數的問題，我的解決方案是
WHERE 1 = 1
AND ISNULL(A.Page_Name,'') LIKE '%'+ ISNULL(@cPage_Name,ISNULL(A.Page_Name,'')) +'%'
可以看出如果是空的化會過濾掉，當然缺點也是有的，就是會多過濾一次篩選 可能會導致查詢速度下降，再實際測試時候沒有發現問題，上百萬級時沒試過(待會試試)
代碼也更好看了 再VS里面是紅彤彤的一大塊 沒有 sb.Append什么的
然后就可以將實體用反射傳參過來了
基本就是這些 歡迎大神補充