回憶第一次接觸三層架構，看那些文章，好像走出了菜鳥的圈子，俺做的項目也是有架構的，還可以到處吹牛，俺的項目是基於***架構的，頗有那些做java的風采。
在網上看到的三層架構大多數這個樣子的，大家最常舉得案例便是數據庫工廠，我們的項目可能是mysql數據庫，也可能是sqlserver數據庫，還可能是未知的數據庫，從那時起，我就知道了接口是什么東西，看了好多文章，也知道了什么叫基於接口的開發。
而且三層架構果然是真的好像商標一樣，出現在各種技術社區，尤其是那些源代碼網站，當時為了學習，也從網上下了很多源代碼進行觀摩，學習，就連面試的時候，都要被問“你會三層構架嗎”，當然，不管會不會，我都是會的，大家懂得。
也不知道是缺乏知識產權保護，還是缺鈣缺鐵，還是缺什么，我下載到的源碼總是這個樣子，開始我以為我是菜鳥，也就只能這個樣子，畢業后進入高手如雲的公司，肯定不是這個樣子。
記得去年在某公司上班，打開項目一看，就好像我已經來過了一樣，項目的名稱都和我的電腦里面的項目差不多，什么BLL什么的。當時我就感覺頭暈目眩，接口！接口！太可怕了，后來我在公司最常干的一件事情就是打電話，電話的內容很簡單，那個誰誰，你把那個什么文件嵌入一下，我要改一下。偶想起來了，還有一件事情也很常見，就是我每打一次補丁，都要發一次郵件，要把所有人問一遍，這個dll能不能作為補丁發出去。
去年年末的時候，看到一本菜鳥進階的書，網友們稱呼為微軟技術百科全書的《微軟技術構架指南》我才知道，原來3層構架乃至n層構架更多的是從部署的角度來來考慮。
我心一涼，心想，我改一個功能時，那么的痛苦，發一個補丁時，那么的痛苦，原來公司的三層架構是山寨的，因為那個dal也罷還是bll也罷不能個單獨拿出來部署在一台機子上，那什么這個東西搞的我如此的痛苦，如此的受罪，寫代碼嘛，應該愉快一點。
后來看了一些書，這個可能和公司的業務性質，項目性質有關，例如做cs的客戶端，可能一年升級一次，半年打一次補丁，但cs的服務器端，可能每晚都要打補丁。做bs的就不用說了，你不打幾個補丁上去，老板都會覺得你是廢物，干了這么長時間，網站竟然每一個新功能，每一個變化
現在大多數公司的架構可能是這樣，一個公司，分幾個產品，由產品經理帶頭，一個產品經理，可能帶一個到三個項目小組，組成一個大的單位，每個月可能是這么渡過的，
所以按照網上流傳的三層架構的，工作必然是辛苦，上線必然是痛苦的，加班必然是難免，新功能和舊功能攪和在一起，BUG總是難免的，搞的我們上班很累。
有時候回憶自己上周都做了什么，寫了幾行代碼，有時候發現，一周干的事情並不多，
不知道大家用過微軟的membership沒有，我現在更傾向於將一個業務模塊或幾個關系緊密的ui用到的一些功能，
向membership一樣獨立的封裝，也許不能去建立一個項目，發布一個dll，但是在原來的項目下建立一個文件夾，來放這幾個類還是可以的，雖然我現在不清楚用什么樣的方式去架構，或組織文件，才能讓每個業務模塊向membership一樣用起來方便，這樣開發方便，打補丁方便，測試方便，升級打補丁方便，
我現在比較喜歡向這個的方向去組織代碼，有時覺得菜鳥用架構一詞不太合適，還是用組織文件和代碼比較合適，菜鳥一定要低調
Product 是具體的業務模塊，這里沒有公共方法，也沒有HttpContext，也沒有sesscion、cookie、cache等行向擴展的模塊，對與每一個小的業務單元，我就建立一個文件夾，
因為vs默認建立一個文件夾就是一個命名空間，必要時候可以獨立發布dll，對與每一個業務模塊我是用部分類來組織的
| public partial class Table | Table.cs |
| partial class Table | TableDal.cs |
| partial class Table | TableMethod.cs |
| public class TableProvider:Table | TableProvider.cs |
方法還可以按照三層架構時去組織代碼，這個業務模塊對外就是一個對象TableProvider，雖然不能向membership那么強大，但現在也只能想到這些。
web常用的sesscion、cookie、cache等，我喜歡用WebExtensions將其獨立封裝，因為這些模塊都是可以擴展的，尤其是從單台服務器到分布式到集群，擴展也在這一塊，業務模塊我覺得變的比較少，所以吧他們獨立拿出來。
上一遍 ：觀察 HTML中id和name 的差異，被微軟忽悠過的同學自動舉手