為什麼國內那麼多公司亂用 C# 的三層架構？

02-12

個人覺得，理解並在合適場景使用三層架構並沒什麼不對。

三層架構見百科詞條：三層架構_百度百科

關鍵還是在做軟體系統(項目/產品)的時候要有分層的思想。

軟體的性能只是一個方向，一個性能很好但卻不可維護或維護成本很高的軟體比一個性能不高但維護性高的軟體可怕也可恨得多。

我在做架構的時候，第一件事就是把公司原來架構里的BLL、DAL、Model文件夾刪除了。後來大家也就忘記有這麼回事了。

這樣做的主要好處只有，維護門檻低，沒有太多經驗的人就可以上手。

分層是為了降低耦合，降低變更需求導致的風險，統一的結構能讓人快速掌握不熟悉的項目。開發的時候不要過度優化，等於到性能問題再說，而且優化的方式也不一定是打穿層級。另外就是一個項目如果開發周期很長，經過很多次需求變更，開發人員甚至是項目帶頭人都換過，很容易讓項目變得臃腫，產生各種冗餘的數據和API，這就項目架構關係不大了，還是看公司的專業程度和人員素質。

貌似因為MS有個示例--PetShop就是這麼組織的，很多人做完整的應用都是這麼入門的...

講真，第一個公司一個垃圾電信報表賬單系統就是這麼寫的。原因是「大拿」說這高級。

最早的時候，在學校老師上課講所謂的「三層」架構是這麼弄的。

根據這個雛形，於是很多同學在學校開發的項目都按這個結構去玩。

到後來，少部分同學發現業務邏輯其實是可以獨立於前端部署的。

依託於某些服務或者介面，業務和前端切割成兩塊獨立部署。前端通過（服務）介面調用後端業務，實現更好的分離。高效方便易擴展，形成另一種並非單是代碼上的分層。

啰嗦了這麼多，其實就想說，是因為很多人並沒有想過或對項目進行過優化，更別說結構優化了，連以前的舊代碼都不想去優化。人家給什麼結構就用什麼結構，所以慢慢的也就這樣了。

還有些公司說反正也達不到那個量級，怎麼搞都沒事。

反正，就是不願意學習和實踐~~~

話說回來，現在的什麼業務框架、開發框架那麼多，使用的人很多，其實也不少人已經開始用新的架構了，但並非自己寫的也沒有對框架進行研究優化的意願。這類傢伙也不明白為什麼要這麼劃分，對於老派開發來說，反而造成調試麻煩部署啰嗦又沒意義。

所以，可能在未來，會出現很多用你所謂的「三層」架構開發卻不知道「三層」是什麼的開發人員。

就用最熟悉的window系統作為例子，大家都配過環境變數為什麼不直接將路徑配置到path下而是通過定義變數然後引入這個變數，以後如果路徑修改只需要修改那個變數的值就行了，這個其實和三層結構一樣的道理，業務發生需求改動的話只需要對業務層進行修改。

公司好多大佬都不會搞架構。。架構師都不管這些。所以就是在升級的時候重做一遍

分層解決的根本問題就是數據層和業務邏輯之間的矛盾，三層是最簡單有效的方法，你說一個curd項目或者一個簡單的企業站點搞個ddd或者abp不是找罪受嗎，其實發現部分公司連簡單三層的代碼都寫的不幹凈，只要知道分層的原因其實怎麼做都無所謂，我最簡單的項目現在razor+ef連三層都不用，當然為了使新的程序員可以快速加入研發還是用主流點的好

Java的角度理解，三層架構就是mvc了。.NET的三層就是代碼拆開寫，不要寫到一個文件里(主要是webform)，當然會用到五大原則和設計模式等，便於審閱和測試

架構這個東西。一般公司不會經常動的。第一代開發人員部署完畢，後期的只是不停的增加業務而已。除非遇到重大問題。業務量增加導致架構無法支撐，必須在代碼層面修改，否則一般不會動這個的。

因為很多東西經歷很多人以後，大家都不知道咋改了。

為什麼國內那麼多公司亂用Java的MVC三層架構?一個簡單的頁面經過這樣的包裝速度完全快不了。

為什麼國內那麼多公司亂用java的設計模式?一段簡單的代碼經過這樣的包裝速度完全快不了。

1：這個3其實不是真的3，是多的意思。至於到底幾層，看項目，看需求，有些東西甚至1,2層就夠了，有些可能10層都hold不住。

2：性能這鍋不背，你不分層提高的那點性能在io面前就是忽略不計

3：那麼別跟我說改成service，repository，domain就nb了

4：那麼你show一個又解耦性能又好的架構來看看

其實。 web的主要壓力基本上來自資料庫。你代碼一層和10層差異是很小的。關鍵還是清晰可讀性高方便維護規範。

我好奇為啥是迷信速度快？不應該迷信這樣耦合低嗎

BLL、Model 模型層，DAL數據訪問層。其實就是兩層吧

三層架構久經考驗，思想成熟，沒有什麼不好。現在流行的一些也不過是n層架構。至於你說的問題，那是開發人員的姿勢水平問題

簡單項目中，資料庫實體類和業務邏輯類基本一致，業務邏輯層中所做的基本也就是寫增刪改查的操作，在這種情況下，三層架構確實有些多餘，個人在處理此類項目一般都是合併數據層和業務邏輯層，在一個類中完成所有操作，有點類似mvc中的controller。但是對於稍微複雜些的項目，數據層和業務邏輯層的分離還是有必要的。很簡單的例子，員工所屬部門這樣一個屬性在資料庫實體類（AccountDAL）中可能只是簡單的設計為 public int FKDpartmentId { get; set; }，而在業務邏輯層（AccountBLL）中可能會這樣設計 public Department Department { get; set; }，對負責view層的小夥伴來講，account.Department.Name 這樣的寫法自然方便很多，邏輯上也顯得更合理。

所謂的三層架構不就是MVC嗎？

學校裡邊老師就一直灌輸的三層，BLL,DAL,MODEL，誰去管性能啊，首先是得實現功能，然後再去考慮性能的問題

都用動軟生成器呀, 對於中小網站來說,我覺得挺好用呀很多代碼都寫好了

我只寫小網站，從來不用三層

還以為是mvc呢

授的是漁，學的是魚