.Net架構必備工具列表

★微軟MSDN：每一個開發人員如今應該下載的十種必備工具

點此進入

★網友總結.Net架構必備工具列表

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服務器!