為什麼國內那麼多公司亂用 C# 的三層架構？
有代碼生成器啊。。。。直接資料庫映射就生成好了，在那個沒有ORM或者說ORM沒那麼流行的年代，這多幸福。。。
這個故事是這樣的，
A方案：老闆花30k的工資雇題主這樣高水平的碼工，做出架構一流的項目，運行在伺服器上cpu跑10%，項目完成老闆收客戶10萬。B方案：老闆花3K的工資雇了一個只會BBLDAL和代碼生成器的碼工，做出垃圾架構的項目，cpu跑50%但是運行還算良好，老闆收了客戶10萬。題主你看，老闆比你聰明多了。看了這麼回答，都是批判的多，首先三層架構並不是解決性能問題，樓主的問題貌似更多的是業務問題，大神們應該給出解決方案，比如你拿出個架構來對比三層架構，能否更有說服力？
發現國內好多用 C# 的公司，都喜歡三層架構。通常他們是建三個文件夾，命名為BLL、DAL、Model，再通過代碼生成器生成一大堆代碼，數據邏輯都要求使用存儲過程。這樣造成了一大堆多餘的代碼，修改麻煩，性能差。可是他們迷信這樣運行速度快。我經過測試後，發現一個簡單邏輯經過這樣的包裝速度完全快不了，並且他們根本不了解三層（數據，邏輯，界面）是什麼意思，他們以為就是建三個文件夾，造成這種錯誤用法是什麼原因？最初這樣錯誤使用的是誰？是誰推廣的？
錯了么?沒錯.
是三層么?是.那麼他們到底存在什麼問題?
其實是對三層的不理解.所謂BLL DAL MODEL.這三個層他們其實對於BLL層是沒有使用到的.對吧整個BLL層都是return.但是這麼做有好處.也是他們這樣做唯一的原因.就是:當真正需要該邏輯的時候.只需要改一個層即可...沒了...框架本身就會造成效率的變低.任何框架都是.這個是首先你必須清楚的知道的.因為Hello Word.跟你寫一個抽象工廠.實現一個Hello Word 是完全不一樣的.效率肯定低到一定境界了.但是錯了么? 沒有.問題問得很low，然後又不給出自己高明的方案。屬於沒弄明白三層架構是為了什麼，應該屬於還沒工作，沒團隊開發經驗一類的在校生。三層架構從來就不是為了所謂的性能，而是為了擴展性，復用性和可讀性可維護性。而且性能的瓶頸絕大多數在資料庫io，文件io，網路io等等io操作上面，遠遠賴不在三層架構上面。大型項目上面，為了擴展性復用性可維護性，架構只會越來越厚。自己寫出屎一樣的代碼，就不要賴在架構上面了吧。規範化的代碼，在團隊合作、分工、擴展、維護角度可以省下許多成本
我覺得做了這麼多年的代碼，還是有資格說說三層架構這個東西的，如果說的不對大家批評指正。
最初我在廈門的一家小公司做倉儲及監控系統，當時使用的是WINFORM程序，之前的軟體工程師為了趕工期，就直接使用了一層架構，所有代碼都放在WINFORM項目。這種做法不太符合我以前接受的教育，最初覺得前輩做的不太靠譜，但是在做了一段時間的維護以後，發現其實也沒什麼問題，就是代碼寫在一起不太好看而已。重點是，這個系統的代碼量不大，只有10萬行左右，結構還是比較清晰的。
後來我們決定把這個軟體改造成網頁形式，於是用EXTJS、http://ASP.NET MVC做了分層，數據層、邏輯層、表現層都分開了。在開發的過程中感覺這個分層結構不太好，因為表現層與邏輯層、邏輯層與數據層有非常多的重合之處，很多內容可以放在邏輯層做，也可以放在表現層與數據層做，邏輯層有點多餘。不過那個時候我初入職場，身邊有兩個大牛，相信前人發明三層必有其合理之處，就這麼一直用著。
13年的時候進了一家大公司，看到了一個相當複雜的下單流程，代碼差不多有三千行左右，當時就驚出一身冷汗：這樣的代碼如果放在同一個文件中，那維護起來是非常非常困難的。於是工程師們分寫了幾個cs文件，把底層的操作都分散出去，主文件中只放了調用流程，這樣主流程代碼就縮到了一千行左右，再用region與endregion隔離開，結構一目了然。
這是我頭一次發現邏輯層的作用，不過像這類代碼量達到幾千行的代碼畢竟不多，我在那公司工作的三年時間裡，總計遇到的不超過20個。我相信每個公司都會有幾個極其複雜的流程，但除了這些複雜的流程之外，其他的流程相對來說都是比較簡單的。在相對簡單的功能中，我們把輸入合法性驗證之類的邏輯都放在表現層的cs文件中，涉及多條SQL的操作則放在數據層中，邏輯層大多數時候就是接收表現層的請求後，直接調數據層函數返回，沒有實際作用。
就這麼說吧，500行以內的代碼，我認為只要用region與endregion隔離開就能夠實現優良的代碼結構，邏輯層並無實際作用。只有在系統中存在大量超過500行代碼的函數時，邏輯層才會顯得極其重要。
隨著工作經驗的增長，我越來越不待見邏輯層。從那個大公司出來以後，我接手了一些比較小型的項目，代碼量從10萬到30萬這樣子的。如果我接手時它是一個不完善的東西，我一般都會花上一周時間，把它改成只包含表現層、數據層的項目，這樣子開發起來的速度加快，而且層次間的結構也比較清晰。
這些年我寫SQL的能力越來越強，甚至於現在敢跟工作了七八年的人吹牛，說一個SQL語句只有你想不出來，沒有我寫不出來的。剛開始工作時SQL能力比較菜，C#用起來很舒服，所以喜歡在C#代碼中寫業務邏輯。後來SQL技能變得過硬，於是遇到問題第一反應就是通過純SQL來解決，數據層的C#代碼只是用來執行一條SQL語句而已。
因為SQL能夠實現的邏輯太多，而且也不像C#那樣需要太長的代碼，所以就越來越喜歡它了。如今再度審視之前的工作，也許大多數的邏輯都可以使用SQL來實現，沒有必要讓C#摻合太多，兩層就足夠了
三層架構並不是解決運行效率的問題的，而是在系統需求發生改變的時候，模塊化的代碼便於修改。
因為Java系至少三層起，你C#的人做東西要是少於3層，豈不是顯得自己逼格比Java系的低了？
估計是微軟的"官方例子" PetShop 影響的.BLL、DAL、Model 這幾個名字都是Petshop里幾乎一樣.
PetShop算啥,更早有個叫"達萬密屎"的書店微軟官方例子.用的是強類型DataSet .七八個工程。用過vs2003的都知道...全都是說不好的，然後就沒一個說要怎麼做才好，或者有哪個來源的分層架構好？
三層架構是為了邏輯簡單，降耦合。你以為項目開發完了就結束了？後面的運維才是重頭戲，出了個問題人家定位不了問題看不懂你代碼怎麼辦
其實你可以提一個自己覺得比這個好的模式，弄出來之後你最好引入一個新成員，讓他接你的項目，然後看一下效果。至於性能，瓶頸肯定不在這個分層上。你確定是三個文件夾么而不是project？可以編譯出獨立的dll單獨被引用的。最後你確保理解了bll，dal和model的實際意義？我的觀點是這種分層在現有的很多情況下是相對好的一種模式，除非你是大牛並且負責項目到死的整個周期，這樣你可以「無招」，否則你還是得有個招。
動軟生成器
單表的 CURD 看不出效果，只有出現複雜的業務邏輯，需要多表操作時，才會發現好處，DAL 的復用，快速添加需求。
前提得使用 EF，T4
推薦閱讀《代碼整潔之道》，代碼不是寫完就沒事了，也不是上線了就不用管了，那只是一個開始，而基礎架構決定了能走多遠
業務不複雜吧，讓你寫個金融系統我估計大部分碼農只能寫v 和m 層
據單位前輩們說他們用了一個會自動生成代碼的軟體生成出來的代碼就是BLL+DAL+Model，當年這個軟體在C#圈紅極一時的時候還沒有現在的Entity Framework，可以說在當年WebForm盛行的時候這套代碼工具極大的提高了開發效率，畢竟基本上都是些增刪改查。
至於在EF都已經跨平台的今天為什麼還有人堅持用，原因很簡單，他們和現在還在堅持用jdk1.5，前端堅持用jQuery的人是同一類人，不想擁抱變化罷了。