Scott等就ASP.NET MVC 1.0编写了Professional ASP.NET MVC 1.0一书，并提供了免费的第一章、第二章下载。其中，第一章以一个完整的案例NerdDinner讲解了如何使用ASP.NET MVC技术对网站进行开发。这个一篇指导意义非常强的教程，对于ASP.NET MVC的初学者是最合适不过的教学案例了。第一章提供了html版和PDF版，EntLIb论坛对 这些内容进行了翻译，提供了比较完整的HTML中文版。HTML网页固然方便，但毕竟过于零散，不如PDF文档显得正式和统一。此外，EntLib对 Scott的案例作了少量的修改，增加了EntLib的标识。同时，该网站还省略了教程中集成地图的部分，我觉得略有遗憾。所以，我在EntLib的基础 上，完善了整个文档的翻译，还原了英文版的本来面目，并提供了PDF格式的文档。
内容包括：
1、创建MVC Web Application
2、创建数据库
3、创建Model模型
4、控制器和视图
5、创建、更新、删除记录
6、模型绑定的安全性
7、ViewData和ViewModel
8、Partials和Master页面
9、认证和授权
10、AJAX实现RSVP响应
11、集成AJAX地图
12、单元测试
13、依赖注入
完整文档下载：ASP.NET MVC Step by Step中文版
最佳的架构、需求和设计出自于自组织的团队。蜂巢中的工蜂们看似忙碌，但其工作却是有序而有效，归根结底就是它们的组织架构其实是自我组织的。在自我组织的团队中，团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估，并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。
自我组织的团队是一个平行的组织，由于没有管理与被管理之间的关系，因而氛围更加和谐，组织更加开放，管理更加松散，这种自由化的组织方式更容易让团队成员体现自我价值，对团队会产生一种认同感，促发他们的开发热情，从而提高开发效率。平等的关系会促进团队成员的有效沟通，自由的管理有助于发挥团队成员的技术特长，开放的平台则能够保证协作的效率。一个卓越的团队应该是目标一致，团结协作，同时又能各司其职，有条不紊。
全文阅读>>
在WS-*标准和规范中，WS-Discovery是在2008年才加入了OASIS标准。WS-Discovery在标准被定义为Web Service Dynamic Discovery，其目的是为定位服务定义Discovery协议，主要应用在为客户端动态搜索一个或多个目标服务。OASIS为WS- Discovery提供了两种操作模式：ad hoc和managed模式。
ad hoc模式根据类型在托管目标服务的范围内查找目标服务。客户端会以多播的形式发送一个Probe（探测）消息，如果服务匹配该信息，则以单播方式直接将响应发送到客户端。为了能够根据名称定位目标服务，客户端会以相同的多播组发送一个Resolve（解析）消息，同样的，匹配该消息的服务会直接以单播方式响应客户端。消息交换的流程如下图所示：
如果Endpoint的数量扩大了，且超出了ad hoc网络的范围之外，而且在网络中可以使用Discovery Proxy(发现代理)，则应该采用Managed操作模式，以禁止多播的行为。在Managed模式下，目标服务只需要以单播的形式发布一个 announcement（通告）消息到Discovery Proxy，同时，客户端也会以单播形式发送Probe和Resolve消息到Discovery Proxy。这种模式并非直接采用单播方式，而是会实时对Discovery Proxy进行监听，然后根据情况切换操作模式，从而降低多播给网络传输带来的影响。当Discovery Proxy检测到在ad hoc网络中有多播方式发送的Probe和Resolve消息时，它就会发布announcement通知自身。客户端一旦监听到Discovery Proxy上的announcement消息，就切换为Managed模式，直接以单播方式将probe和resolve消息发送给Discovery Proxy。如果Discovery Proxy没有响应，客户端又会切换为ad hoc操作模式。Managed模式的消息交换流程如下所示：
WCF 4.0实现了OASIS的WS-Discovery标准，相关的类定义在System.ServiceModel.Discovery命名空间中。这是一个单独的程序集，所以需要添加对它的引用。如下图所示：
WCF Discoverty支持ad hoc和Managed模式，其中实现Managed模式需要实现Discovery Proxy。相关内容我会在另外一篇文章中讲解。
在WCF 4.0中，新增了ServiceDiscoveryBehavior行为类，可以控制服务终结点的可发现能力。它能够让服务的所有终结点都能被发现，相反，如果使用EndpointDiscoveryBehavior则只能使特定的终结点能够被发现。除了需要添加发现行为，我们还需要添加发现终结点，用来指定监听以及发送discovery消息。WCF中标准的发现终结点类是UdpDiscoveryEndpoint，它基于UDP的多播绑定，是WCF 预先配置好的发现终结点。该终结点继承自DiscoveryEndpoint类。在托管服务的时候，我们可以向ServiceHost中添加 ServiceDiscoveryBehavior和EndpointDiscoveryBehavior，如下所示：
class CalculatorServiceHost {
public static void Main() {
Uri baseAddress = new Uri("http://localhost:8000/" + Guid.NewGuid().ToString());
using (ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService), baseAddress)) {
serviceHost.AddServiceEndpoint(typeof(ICalculatorService), new WSHttpBinding(), String.Empty);
// Make the service discoverable over UDP multicast
serviceHost.Description.Behaviors.Add(new ServiceDiscoveryBehavior());
serviceHost.AddServiceEndpoint(new UdpDiscoveryEndpoint());
serviceHost.Open();
Console.WriteLine("Calculator Service started at {0}", baseAddress);
Console.WriteLine();
Console.WriteLine("Press <ENTER> to terminate the service.");
Console.WriteLine();
Console.ReadLine();
}
}
}
在对服务宿主进行如下设置之后，客户端就可以通过发送Probe和Resolve消息来发现服务。WCF将这些逻辑封装在了DiscoveryClient 类中。它接受一个发现终结点对象，然后通过调用它的Find()方法（该方法接受一个FindCriteria实例，用来指定搜索标准，在下面的代码片断中指定搜索标准为按照目标服务的类型），返回FindResponse对象。该对象会包含一个 Collection<EndpointDiscoveryMetadata>类型的属性Endpoints：
// Create DiscoveryClient
DiscoveryClient discoveryClient = new DiscoveryClient(new UdpDiscoveryEndpoint());
Console.WriteLine("Finding ICalculatorService endpoints...");
Console.WriteLine();
// Find ICalculatorService endpoints
FindResponse findResponse = discoveryClient.Find(new FindCriteria(typeof(ICalculatorService)));
Console.WriteLine("Found {0} ICalculatorService endpoint(s).", findResponse.Endpoints.Count);
Console.WriteLine();
if (findResponse.Endpoints.Count > 0) {
return findResponse.Endpoints[0].Address;
} else {
return null;
}
通过WS-Discovery，我们不需要知道WCF服务的终结点，只要存在目标服务，我们就能够动态查找到该服务。即使服务的Url发生改变，我们也不需要修改任何代码和配置文件，客户端仍然能够正常发现目标服务。
秉承敏捷宣言的精神（个体与交付重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划），我认为，敏捷开发大致应该体现如下的思想：拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。
1、拥抱变化
Kent Beck和Martin Fowler在介绍极限编程（eXtreme Programming）时，最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度，那就是不拒绝，而且还要主动求变。有一句经典的论断说得好：“在软件开发领域中，唯一的不变就是变化。”其实，不仅仅是软件开发领域，世间万事万物都处在永恒的变化之中，这是宇宙的基本规律。奥巴马在竞选美国总统的时候，提出的口号就是“变化”。变化才是真正的常态。
全文阅读>>
设计模式最经典的书籍自然是GOF的《设计模式》，但很多人的反应是这本书太难理解了，并不适合初学者阅读。这话说得在理。一方面，本书使用的C++示例难倒了一大群Java和.NET的开发人员；另一方面，这本书的风格过于专业化，更偏向于学术论文的风格（事实上，本书的雏形就是来源于GOF中Erich Gamma的博士论文），因此就显得有些晦涩难懂了。
基本上，本书可以作为我们参考的标准，是经常查阅的文献资料。如果你对某个设计模式还有困惑不解之处，阅读本书，然后细细品味，总会给你一些豁然开朗的感觉。夸张点说，这本书可以说是设计模式的红宝书，即使人手一册，也不为过。说句题外话，我还是喜欢外版书的封面设计，给人一种艺术的美感，让人看着就有想买的冲动。国内专业书籍的装帧与设计，做得好的，真的很少。
对于设计模式，这几年被人广泛推崇的还是这本Head First Design Patterns，中文版被译作《设计模式深入浅出》。书名就代表了本书的性质是面向初学者的。而它的著作风格才是真正引人注目和称道的。专业书籍的风格通常会存在迥然不同的两种风格。一种风格深入浅出，趣味盎然，阅读过程轻松愉快，而给出的实例也多以生活中的例子进行类比，帮助读者对书内容的理解。这本书就是这一类书籍的个中翘楚。
去年在国内计算机图书界，独领风骚的一本《大话设计模式》，同样属于这样的风格。程杰也因为该书在去年荣获了51cto的年度IT图书的最佳原创作者奖。该书的成功就在于它继承了这样一种集娱乐与技术为一体的独特风格，让技术人员看到，原来，技术书籍也可以这样写，读起来也可以这样有趣。至于另一种写作风格则偏向于循规蹈矩，描述技术问题胜在其条理清楚，如山涧流水，优雅而从容，却最终能够融汇成一条大河。很难说两种风格孰优孰劣，前者胜在趣味，后者胜在严谨。我并不是说有趣的书就一定不严谨，只是相对而言，一本书若要有趣，就必须给出生动的比喻或者隐喻，而这样的修辞总会或多或少使其本质发生小小的变形。然而这两种风格，若要成功，最关键的还是要看著者的技术功底和笔力。
虽然设计主要还是要看思想，但很多读者还是比较在意每本书的代码载体。Head First Design Patterns一书给出的是Java示例，而《大话设计模式》则是C#。还有一本面向初学者的好书是阎宏先生所著的《Java与模式》。本书利用中国传统文化来阐述设计之道，又引入了大量的Java实例，尤其是对Java的API或框架进行了深入分析。所以读来既有趣味，又有文化的底蕴，同时还不乏实际的例子给出标准的范本。我以为，对于初学者，本书是再合适不过的了。
若要理解UML，并将软件开发和设计有效地与UML结合起来，那么最佳的选择是阅读Craig Larman的经典著作Applying UML and Patterns。本书已经出版到第三版。一本书若是能够再版、三版，绝对有其值得称道之处。该书全面地介绍了RUP开发模型，并将UML与开发过程、设计模式等有效地结合起来。随着本书章节的逐步演进，读者的能力也将得到逐步的提高。本书的中文版名为《UML和模式应用》，似乎现在仅出版了第二版的中文版本，不由不让人感叹我们总是在追着技术前进的步伐在跑，甚至是优秀书籍的出版，我们也是在后面追赶着，却始终追赶不上。
将敏捷、面向对象思想、设计模式有机结合起来，会是哪一本书？还用问吗，自然是Bob大叔的巅峰之作Agile Software Development: Principles, Patterns, and Practices了。本书中文版的译者邓辉先生功底扎实，比较好地将原书的神韵传达了出来。
若要问哪些书（当然是指技术书籍）可以让我重读不厌？那么这本书一定要排在前列。实际上，像这一类的书籍都是值得反复阅读的，因为每一次阅读，它都会给我们新的启发与体会。所谓“读书百遍，其义自现”。技术书籍本身存在一定的难度，不同水平的人阅读同一本书的收获是大不相同的。而在不同阶段的同一个人，因为技术水平的变化，自然每次都能够读出新意来。本书附带的代码是Java，同时还包含少量C++代码。之后，Bob大叔又推出了该书的C#版，算是满足了广大的C#开发者的强烈需求。
即使是最优秀的设计师，也不可能总是在第一次就能将设计做好，因而我们需要重构。讲解重构技术的书籍中，最声名显赫的无疑就是Martin Fowler的Refactoring: Improving the Design of Existing Code。正是本书开创了重构在软件开发中的光辉地位。这本书的优秀自然不用我再来饶舌了。Martin Fowler先生是全球知名的软件大师，他的每一本著作都给业界带来了深远的影响。我在一次和Fowler先生的面对面交谈中，曾经问他至今最满意的著作是哪一本。他没有丝毫的犹豫，就回答是Refactoring。
本书的中文版名为《重构：改善既有代码的设计》，译者为侯捷和熊节。熊节是敝同乡，我和他有过一次面谈，谈起过这本书的翻译。那些翻译的往事也让他感触颇多吧。本书真正称得上是软件书籍中的名著名译。熊节的中文和英文造诣都很厉害，所以阅读本书的中文版，你几乎感觉不到有“隔”了一层的晦涩。通篇阅读下来，就是那么流畅。顺带提及，本书是少有的中文版封面设计优于原版设计的特例。
虽然说Martin Fowler是重构技术的集大成者，书中提到的重构方法也多数用到了设计模式，但真正将重构与模式结合起来的，还是Joshua Kerievsky，他的著作Refactoring to Patterns 也曾经荣获了第15届Jolt大奖。书中强调：“‘通过重构实现模式、趋向模式和去除模式’，而不再是在预先设计中使用模式，也不再过早地在代码中加入模式。”实际上，这样的论调恰恰迎合了敏捷社区的需要。极限编程的实践就要求简单设计和设计改善，改善的方法就是利用重构合理地引入设计模式，以期改善程序的结构，使其具有更佳的可复用性和可扩展性。此外，本书还是Refactoring: Improving the Design of Existing Code一书的补充，增加了诸如用Factory Method引入多态创建、将聚集操作搬移到Collecting Parameter等重构方法，明确地把设计模式作为重构技术的一等公民。本书在大陆的中文版为《重构与模式》，而在台湾则被候捷和陈裕城译作《重构-向范式前进》。虽然名字不够精简，但却真正地代表了作者创作本书的含义，就是从Refactoring到Patterns。
虽然Martin Fowler最看重Refactoring: Improving the Design of Existing Code一书，但我个人认为，他的Patterns of Enterprise Application Architecture一书（中文版名为《企业应用架构模式》）价值更高，因为它为我们设计人员给出了全面、深入、权威的企业级设计指引。
在所有的软件大师中，或许Martin Fowler是最善于总结的一位。他虽然没有提出具有独创性的方法与思想，但很多独创性的方法与思想到了他的笔下，都能化腐朽为神奇。本书最好地印证了这样的奇迹。在本书诞生之前，实际上关于分层设计、并发处理、对象关系映射、表现模式以及分布式处理，已经有了许多非常优秀的实践。但只有Martin Fowler凭借自己丰富的技术经验与无与伦比的创作能力，将这些散落的珍珠串联在了一起，最后形成了一串璀璨夺目的项链。透过本书，Fowler将自己善于总结的能力发挥得淋漓尽致，真可以说是“笔落惊风雨，书成泣鬼神。”
Martin Fowler的早期著作中，Analysis Patterns提出了领域逻辑的诸多建模原则和模式，不过真正对领域建模、分析和设计产生奠基作用和推动作用的，还是Eric Evans的大作Domain-Driven Design，中文版名为《领域驱动设计》。本书的诞生推动了一种设计方法，改变了传统通过数据设计驱动开发的模式，而是将核心关注点放在了领域逻辑上，而这应该说才是真正的软件设计的正道。
Martin Fowler在本书的序中，这样写道：“控制复杂问题的关键是建立一个好的领域模型，它越过问题域的表象介绍其底层的结构，给软件开发人员提供所需要的方法。”毋庸置疑，当我们面对复杂多变的领域逻辑时，领域驱动设计已经成为了我们手中的利器。掌握领域驱动设计，并不能保证所有复杂的设计问题都能够迎刃而解，但这种思想却能够帮助我们像庖丁解牛一般，即使面对纷繁复杂的领域逻辑，也能够做到“以神遇而不以目视，官知止而神欲行”。
本书堪称经典，正如Kent Beck的推荐：“每个有思想的软件开发人员，其书架上都应该珍藏这样一本书。”说起来，我也是Kent Beck提到的“有思想的软件开发人员”了。