程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> C# >> C#入門知識 >> .Net架構必備工具列表,.net架構必備工具

.Net架構必備工具列表,.net架構必備工具

編輯:C#入門知識

.Net架構必備工具列表,.net架構必備工具


N多年前微軟官網曾發了.Net下必備的十種工具,N多年過去了,世異時移,很多東西都已經變化了,那個列表也似乎陳舊了。而且,該文也只是對十種工具獨立的介紹,顯得有些羅列的感覺,是不是每個工具都是同等重要,工具與工具之間是否有聯系?等等,闡述得並不明確。

這裡,我想從另一個角崖,重新歸納一個更新的更實際的武器庫。更新,是因為有很多最近幾年才出來的工具/框架庫,更實際,是因為我自己的項目就完全依賴使用。

Visual Studio

這個似乎是不言而喻的,只是從嚴謹的角度,也列在這。實際上,現在也有一個開源的IDE開發環境發展也不錯,叫SharpDevelop。我並沒有仔細看,不敢妄評。而我因要用到之後會講的Resharper,也迫使我只能用VS。

Resharper ---重構必備

無論是從其名稱,還是實際功能,Resharper絕對稱得上利器,一旦你用熟了你就再也離不開它了。我去年換工作,很大一部分原因就是因為原單位不讓我使用Resharper。幾個面試,我也總在重復提出我這一要求。直至最新版本6.1為止,Resharper已經是個多面手。早期,它還只是個重構的工具,如今它是反編譯器(原來的Reflector.Net就用不上了),還是個代碼審查工具(代碼規范審查),還是代碼生成器(Code Smith又用不上了),最後,它對鍵盤快捷鍵的組織使用,對無鼠標操作極其有益。一句話,Resharper能極大提高編碼的效率,利器更是重器。

Fluent nHibernate --- 域驅動DDD必備

這件武器其實分為兩部分,一個是Fluent,一個是nHibernate (這不是廢話)。nHibernate知道了解的人很多,就是一個ORM工具,而加上Fluent之後就知之甚少了。從功能上,Fluent只是在原來 ORM工具基礎加上一層封裝,以Fluent Interface形式提供了使用nHibernate的API。可是別小看這一層封裝,從使用體驗和效率提高方面,Fluent nHibernate有著卓越的功效。就我個人經歷,就是在Fluent nHibernate之後,才真正使用,喜愛上nHibernate本身。讓大多數人比較頭疼的創建映射XML文化,被全部C#文件代替,甚至可以完全省略。可以說這兩部分是一個完美的結合,後者提供強大的基礎功能,前者提供完美的使用接口。這不是一個成功軟件必須的兩個要素嗎?什麼是ORM,不會吧,放狗搜搜就知道了。我只想強調的是,不要把它僅僅看作一個功能庫,它更是個架構設計的利器。從架構的角度,它把業務域和數據層隔離,使得數據模型和業務域模型獨立設計成為可能。這一點的影響是非常深遠的。

nUnit + Machine Specification + Rhino Mock + AutoMocking --- 單元測試必備

啊呀,不得啦。上一武器,我一下子介紹倆,這一次白送四個。這也體現我寫本文的指導思想,從開發使用的角度來敘述而不是從工具提供者來還分。這四個套件在一起實在是太完美了!nUnit又是一個眾所周知的測試框架,它提供了測試的基礎功能和概念。MSpec從BDD的角度,封裝了一下nUnit,也可以說是重構了一下語法,使測試可具有可讀性,提供良好的測試組織結構,進而可以測試完了,直接生成一個完美的測試結果文檔。Rhino Mock也是一個熟客了,但是舊中有新,新的幾個版本也加入了一些可圈可點的新性能,如所謂AAA語法(Arrange, Action, Assert 這與MSpec的 Establish, Because, It關鍵詞完全契合)。而從我的角度,看到的亮點仍然是可讀性的改進。最後,AutoMock的出現又讓事情更加簡單了,連創建Mock對象的語句都省掉,只要你把依賴類的接口,在被測試的類的構造器中聲明傳入,AutoMock就自動為你創建Mock對象就,如同它的名字所表達的一樣自動Mock。當然,還有高級應用,暫不贅敘。

SQLite  --- 集成測試必備

什麼,數據庫也算?是的,不過這裡SQLite不是我的產品數據庫,而是用它的內存數據庫做集成測試的工作,可以說是集成測試的利器。I\O讀寫歷來是性能的瓶頸,而敏捷編程對測試的高度依賴,也是對測試性能的高度要求。即使是高度覆蓋率的單元測試也仍然不夠,我們依然希望能在持續構建(CI)中,每次能自動運行集成測試。而如果要有真正獨立、干淨的集成/用例測試,最好是每個測試用例完全重建數據庫,重置測試數據,這樣的要求,只有內存數據才能得到良好的性能。使用SQLite證的內存庫後,不光集或服務器可以輕快的完成集成測試。開發人員本地,也把集成測試很快的運行完。這樣,我們的敏捷流程中不僅包括單位測試必須通過,甚至也包括了集成測試。它的名字叫用戶故事。

不過這個工具有個小小的問題,因為SQLite是基於C開發的,針對32位和64位系統,它分別發布了兩套控件,所以你必須根據自己的平台,3引用不同的Dll文件。而且,VS項目編譯設置還必須明確指明是x86還是x64,不能設為Any CPU。就為這個由題,我很是頭疼了幾天,最後才找到這個解決方安案。使用上,由於前面使用了Fluent nHibernate,除了配置,不用對代碼做任何改動。如果要改改了,也就不是真正的集成測試了,不是嗎?

Git  --- 源代碼管理必備

如果你能一天就把代碼寫完,你就不需要源代碼管理,你能嗎?做為一個源代碼管理的新秀, Git的發展是極其迅猛的。我看好它,是它優秀的底層設計,優秀的業務模型. 如果要了解什麼是DDD,Git是一個非常好的典范。一般的源代碼管理,都是基於單個文件的版本控制,而Git一開始設計就是基於每個提交(代碼文件樹) 來追溯版本。你可能會不贊同我的說法,因為,很多代碼控制仍然提供了項目級的分支或者版本,其實那只是一個假像。VSS,SVN,TFS的最底層,都先是文件版本控制,在這個基礎之上,再提供項目版本的功能。而Gif卻恰恰相反。這個很重要嗎?是的,區別非常之大。引用DDD的思維,即然,從用戶的角度,代碼控制版本是基於文件樹的,為什麼你的業務模型卻不是呢?所以,我把耙VSS,SVN等的這種實現方式,看作打補丁/修補方式,總有一天,補了摞補了,至於最後,再也不能修補了。還有一點Git是分布式代碼管理庫。

TeamCity  --- 持續構建必備

噓(抹汗),總算到講到最後一個,已經寫得太長太多了,寫者累,看者煩。從CI工具的鼻祖CCNet升級到TeamCity之後,感覺確實不一樣,鳥槍換炮。為什麼要CI,好像不是我這一篇短文可以討論清楚的。

TC的好處,第一:是商業軟件並且免費,一般這兩點很難同時出現。當然有個限制,如果你只使一個編譯代理服務的話,這個對我來說已經足夠。第二:它對很多三方工具支持做得很好。如, nUnit, MSpec,Git等。最重要的是它是CI服務器!

  1. 上一頁:
  2. 下一頁: