.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服务器!