我是一名杯具的.NET程序員。學校裏學的稍微過得去的只有c語言。畢業的時候總算有家公司收留做嵌入式開發，工作3個月嵌入式部門轉移到外地，我一直堅定的留下來，去了公司.NET部門學習.NET.
衡量一個程序員的水平不是看他懂多少東西,會不會OO或者別的,而是要看他的代碼是否易懂,是否高效,是否能靈活擴展.能做到這些管他什麼OO,AOP,SOA,MVC,N層架構之類的.記住,能夠以更好的方法解決切實的問題纔是王道.
這是一個神奇的部門，他們中大部門有很多年的java開發經驗，現在他們都在.NET門下，他們一邊對java語言這麼多年發展緩慢發出恨鐵不成鋼的感嘆，同時又對在C#相對強大的功能的支持下.NET居然沒多大建樹而倍感奇怪，他們總是用java的思想來架構.NET的程序, 跟着他們倆年我倒是沒覺得有什麼奇怪，因爲我之前只會c語言。
後來，我辭職去了其他公司，碰到不少.NET程序員，就有點明白他們的感嘆了，也是鬱悶與糾結之開始。
很多.NET程序員OO思想很薄弱，以B/S模式來說，他們的三層架構是這樣的，他們的項目中會有三個類庫工程，而且名字都取的差不多，一個Xxx.Model, 一個Xxx.DAL, 一個Xxx.BAL. Model層就是數據庫表的映射，字段與屬性一一對應。 DAL層就是大段大段的拼接sql字串的邏輯，因爲是拼接邏輯代碼中都是用string=’ ’，而不是string.empty, 到處都是str= str1 + str1，很少用StringBuilder。BLL層就是大段大段根據業務生成字串提供給DAL層拼接成sql，不好拼接的就用視圖，複雜一點用存儲過程，在複雜一點，視圖加數據庫自定義函數之糾結，再再複雜，視圖，存儲過程，自定義函數與DAL層sql之糾結至死。
最後，結果就是所有的類都只有方法，沒有屬性，很多方法都是向下層委，很多方法都可以是static的，甚至可以全是static的，正是因爲沒有屬性，他們的類可以輕鬆的用move method進行重構（^_^ ，汗,調侃），因爲任何方法放在任何類裏不會出錯
你要是和他說你的代碼不OO，就有兩種典型的情況，第一種：我的代碼怎麼不OO了，你看這麼多類，你看這麼多層，我怎麼不OO了，我用的純OO的C#哦，怎麼不OO. 第二種：OO也不能解決所有問題，這三層架構是經典架構啊，是OO的改進，微軟推薦的做法。對於第一種，我基本保持距離，那是OO門外漢，搞不好還是編程門外漢。對於第二種，用C#這種純OO語言，基於.net framework這樣純OO架構的框架做開發，不用面向對象的思想來設計程序架構你打算什麼時候用啊？用C++的人不利用面向對象的思想來設計他的代碼，還用C++幹什麼，用C多直接。究其原因是.NET程序員不知道三層架構某種程度上和OO是有衝突地，屬性和操作分離違背了類的基本定義。雖然三層架構對java來說也是一樣有矛盾的，但人java至少還知道這個問題啊，所以有貧血模型，充血模型，領域模型，ORM之類的試圖解決這樣的衝突。還有中觀點更少數更讓人糾結，說程序員只要是利用OO研究的成果，按這樣的意思，用純對象語言編寫過程式的程序，利用面向對象的.net framework也行啊？這不有病嗎？
.NET程序員大部門不知道依賴注入，不知道面向方面（切面）編程，所以給他們介紹Spring.net, ObjectBuilder,他們就難以接受，拒絕的理由就讓我鬱悶，有用框架啊，有多寫好多類，這麼多配置啊，對性能有影響吧。所以他們的代碼中，”函數三段論”在每個函數都有，這三段就是：執行邏輯，寫日誌， 處理異常，重複的三段論看着很糾結。 最後，就算是微軟企業庫中的DataAccess Block他們也很難接受，因爲他們鍾愛的是SQLHelper。
每次有項目來，在我還在規劃有什麼類，有什麼屬性和操作的時候，很多.NET程序員數據庫中表都已經建好了。我並不反對先建數據庫，不過數據庫與對象如何銜接就得要先考慮了。但是他們並不瞭解關係模型與對象模型之間的區別。所以再建好了數據庫之後，就
開始建個模型。建完了總得要操作數據庫吧，所以再建個DAL，但是現在什麼業務邏輯都沒有，所以DAL層就開始組合下sql語句的拼接邏輯，然後上層就可以提供字串給DAL拼湊了，上層是什麼，BLL啊，最終，把整個程序掃一遍你就發現，編程就是sql字串到處流動並在流動中由短變長，由簡單變複雜。要不就是sql寫在存儲過程中，程序是存儲過程執行的條件到處流動。如此鬱悶之糾結，你一眼看上去還以爲是個字串或者文本處理程序。
總結，都已經到了後OO時代了，.很多net程序員依然還以青銅時代的觀念和方式使用熱兵器