October 2007 - Posts
Check it out - http://events.live.com
www.evite.com 运行了已经不少时间了，现在Windows Live也推出了这样的服务:
【原文地址】ASP.NET MVC Framework
【原文发表日期】 Sunday, October 14, 2007 10:41 PM
过去的几年里，很多人要求ASP.NET的一件事情就是对使用基于model-view-controller（模型-视图-控制器,简称MVC）架构来开发web应用的内置支持。
上个周末在Austin举行的Alt.NET大会上，我首次对我的团队正在开发的新ASP.NET MVC 框架作了一个公开的演示。你可以在Scott Hanselman这里的博客上观看我的讲座的录像。
我们将在今年稍后发布该框架的一个公开预览版，然后在明年的上半年将它作为完全支持的ASP.NET特性推出。
模型-视图-控制器(MVC)框架是什么东西？
MVC是个将一个应用的实现分成三个组件角色的框架技术：模型，视图和控制器。
- 在基于MVC的应用里，Model(模型)是负责保持状态的应用组件。这个状态通常都持久于数据库之中（譬如，我们也许会有一个Product（产品）类用来代表SQL中的Products数据表中的订单数据)。
- 在基于MVC的应用里，View(视图)是负责显示用户界面的组件。这个UI通常是使用模型数据来创建的（譬如，我们也许会生成一个Product"编辑"视图，根据当前Product对象的状态，显示文本框，下拉框和复选框等)。
- 在基于MVC的应用里，Controller(控制器)是处理用户交互，操作模型和最终选择用哪个视图来显示UI的组件。在MVC应用中，视图只是用来显示信息而已，是控制器来处理和回应用户的输入和交互的。
使用MVC方法的一个好处是，它有助于促进应用中模型，视图，控制器间的关注的清晰分离。保持关注的清晰分离使得对应用的测试极其容易，因为不同应用组件间的契约的定义和表达是更明确的。
MVC模式也有利于促进红/绿式测试驱动的开发 （TDD)，通过它，你可以在你实际编写应用代码本身之前首先实现自动化的单元测试，这些单元测试定义和核实了新代码的需求。
ASP.NET MVC 框架的一些简要细节
在几个星期后，相关代码可以下载之后，我将写一些关于这个新的ASP.NET MVC 框架的深入性的教程贴子（与此同时，想进一步了解它的最佳方式是观看我的Alt.net讲座的录像）：
这里是关于ASP.NET MVC 框架的一些简要细节：
- 它将促进清晰的关注分离，可测试性，和TDD。MVC框架中的所以核心契约都是基于接口的，可以轻易地通过mock来模拟（包括基于接口的IHttpRequest/IHttpResponse这些基本的东西）。你可以不用在ASP.NET进程中运行控制器（这使得单元测试很快），就单元测试你的应用。你可以使用你想使用的任何单元测试框架来做单元测试，包括NUnit, MBUnit, MS Test等等。
- 这个框架具有高度的可扩展性和可插拔性。MVC框架中所有的东西都是这样设计的，它们可以被轻易地替换掉或者定制（譬如，你可以插入你自己的视图引擎，路径转向策略（routing policy），参数序列化等等）。它还支持使用现有的依赖注入（dependency injection）和控制反转（IOC）容器模型（Windsor, Spring.Net, NHibernate等等）。
- 它包括一个非常强大的URL映射组件，允许你使用非常干净的URL来建造应用。URL不需要拥有文件扩展，是设计来轻松支持SEO和REST友好的命名模式的。譬如，在我上面的项目中，我可以轻松地把/products/edit/4映射到ProductsController类的Edit方法上，或者把 /Blogs/scottgu/10-10-2007/SomeTopic/ 映射到BlogEngineController类的DisplayPost方法上。
- MVC框架支持将现有的ASP.NET .ASPX, .ASCX,和 .Master 标识文件当作视图模板（view template)之用(这意味着你可以轻松地使用很多现有的ASP.NET特性，象嵌套的母版页，<%= %>块 ，声明式服务控件，模板，数据绑定，本地化等等）。但是，它不使用现有的将交互返回服务器的postback模型，取而代之的是，你将把用户的所有交互转给控制器类来调度，这有助于关注的清晰分离和提高可测试性（这也意味着，在基于MVC的视图内没有viewstate或page的生命周期之说）。
- ASP.NET MVC框架将完全支持象forms/windows认证，URL授权，成员/角色，输出和数据缓存，session/profile状态管理，健康监测，配置系统，以及provider架构等等现有的ASP.NET特性。
结语
如果你正在想使用MVC方式建造你的web应用的话，我认为你会发现这个新的 ASP.NET MVC 框架选项非常干净，而且容易使用。它将允许你在你的应用中很轻易地保持关注分离，而且有助于进行干净的测试和TDD。
几个星期之后，我将撰文说明新的MVC特性的工作原理，以及如何利用它们。
希望本文对你有所帮助，
Scott
我们知道MOSS2007企业版提供了Excel Service，通过ES，我们可以通过一个网页浏览一个Excel文件，甚至通过这个页面输入一些数据进去以获得不同的计算结果。
如果我们需要在某些页面上通过Web部件来展现一个Excel文件，则可以通过一个叫“Excel Web Access”的内置Web部件。这个部件功能很全面，支持与其他筛选Web部件进行连接，来展现不同的内容。
这个Web部件可在激活了企业版功能的网站集中找到，位置是在“企业数据”分类下。
使用方法可参考这几个链接：
在 Excel Services 中查看已命名项目
http://office.microsoft.com/zh-cn/sharepointserver/HA101054732052.aspx
在 Excel Web Access 中显示 Excel 工作簿
http://office.microsoft.com/zh-cn/sharepointserver/HA101054592052.aspx?pid=CH101768472052
将筛选 Web 部件连接到 Excel Web Access
http://office.microsoft.com/zh-cn/sharepointserver/HA101054702052.aspx?pid=CH101768492052
Excel Services 和 Excel Web Access 简介
将 Excel 工作簿作为“一个事实版本”发布的指南
此外，这个Excel Web Access和内容查询web部件一样，必须在激活了企业功能的SharePoint网站集中才能使用。并且，不能用在“我的网站”里：
<quotation url = "http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1826230&SiteID=1">
Problem solved.
Microsoft tech support patiently figured out that the Excel Web Access web part is not available to add to a web part page in a MySite (which is where I was trying to use it) but is available in a portal site (which I hadn't experimented with).
P Taylor
</quotation>
[原文作者]：Slavi Marinov
[原文链接]：How do we write software at Microsoft: a PM intern’s perspective #1
现在对于我们的团队来说，是时候干点实际的了，我们在这里开发软件，所以让我们来谈谈软件。我答应过要把这里最新的东西展示给大家，我决定以"在微软我们怎么开发软件:一名准项目经理的视角" 为题发表一系列博客， 期望能尽可能的迎合开发以及测试人员的口味。
虽然我们的团队很小并且项目生命周期可能也会相对较短（仅3个月），我相信经过这一系列，你将会对发布一个产品需要投入多少精力有个概念，还有为及时发布正确的产品这里的人又投入了多少激情。
好吧， 让我告诉你一些更多的细节,关于近几周让我一直忙碌的事情来开始这个系列吧
项目生命周期
对于每一个项目来说，都会经历一些标准的过程，每个阶段都从前一阶段收益，并且为项目增加价值。毫不奇怪 ，项目要从分析阶段开始，其基本思路是确定项目的范围，确定我们该做哪些，而哪些应该放到下一个版本。 紧接而来的就是规划阶段，项目的发展线路应该如何，(重要里程碑)将会被确定以及划分 这将基本上告诉我们现在项目进行到哪儿了，并且可以在我们和计划的进度不符合的时候，迅速地让我们作出反应。再后来，项目将进入开发等等的阶段。
从最初的两个阶段得到的最重要的两样东西就是项目规格书和项目计划。 没有确定项目范围而进行项目计划是一件很难的事情，所以对于一个项目经理来说首先并且最重要的事情就是确定项目规格书。 因此，这次我将着重介绍项目规格书，并且在以后我将逐渐介绍如何做项目计划。
分析阶段
如果你没有多少写项目规格书的经验，你可能会惊讶与整个团队会为了完成项目规格书花费如此多的精力。 没错，整个团队-写规范是一个团队的努力，如果你认为这是一件只项目经理做的，那么请试着考虑下列各点：
- 开发团队需要项目规格书以便于开始开发，这样他们才能知道要开发什么，他们最终的劳动成果看上去应该是个什么样子
- 测试团队需要项目规格书告诉他们所期望的行为是什么，以至于他们可以开始测试
- 整个团队需要项目规格书用以界定任务，优先级，阶段划分，以及项目的发展蓝图，并且估计出该项目交付的时间
- 各有关方面要规格书以了解哪些功能将在什么时候交付
正如你看到的，一个项目经理能是不可能独立完成项目规格书的（任何在微软工作的项目经理）。 原因有太多的人参与，你不能独自一个人完成项目规格书，然后希望其他人全都同意。所以，如何在微软写出适当的项目规格书 ？ 这里是我的基本步骤。
第1步. 做足功课
我一开始将对该领域做一些研究。 我尝试不同的东西;分析各种可能性，验证项目中的概念等等。我花了相当一段时间扮演一个潜在用户的角色，看到底我需要什么，我期待的产品是什么样的。 所以，我要说第一步是通过实验我们要了解项目看上去应该怎样，探索未知的区域。 这个阶段是纯理论的研究，此时你只需要尝试该领域的一些东西并取得一些经验。 我在做Visual Studio系统的项目中学到了很多，所有那些不同的东西你都需要做扩展，VB运行时包括什么，它是如何实现的，还有许多令人兴奋的事情。 事实证明了当我做为项目的项目经理的时候，我学到了多新东西！
第2步. 多和别人交流
我跟很多人交谈过。 在过去几个星期里，我几乎每天都开几个小会议，为了使项目规格书更加完善，我每天要送出数十份电子邮件。 我已花了不少时间与开发人员，测试人员，项目经理以及其他这个项目相关的人。当我需要一些我自己并不在行的技术方面的支持的时候，我也会和VB组之外的很多人进行交流。 我认为这是一个整个项目最酷的部分-实际了解了不同人对于项目的感受，什么是技术上的可行性，等等
这个阶段很有趣，但并不是写文档本身让我感到高兴。 当然我乐于看到一份文档变得越来越充实，更多细节以及内容被充实进去。 更令人振奋的是，事实上在你完成项目规格书的同时，你真正明白了整个项目在做什么。 你将知道每一个功能细节，因为这是你的工作。 这是不是不可思议？ 你其实有责任了解这一切，所以，当有人有问题时，你知道答案。 我不知道别人怎么想，但我确实喜欢这种感觉。 在某些点上，你对整件事是如何工作有个完整的理解，如何将不同的模块整合在一起，他们将如何互动，有什么潜在的问题，等等。我想让我开始参与软件开发的想最重要的原因，是有机会去创造，建立，创新。
第3步. 让所有人快乐
好了，我花了一段时间写项目规格书，我终于完成了一个说明项目是做什么的文档。。 最好的部分来了-让所有的人同意我写的东西。
基本上，为了使所有人同意，你可以做两件事：
- 要么用枪瞄准他们的头:)
- 或和他们进行会议，这样你就能看到是什么困扰他们，并整理每一个你得到的评论，这样你就能另大家都对产品满意，并且相信项目规格书包含了可使他们开始工作所需要的所有信息。
在微软我们很人性化，所以我们偏向于第二种办法。 我们进行了一系列对项目规格书草案的校阅，这些基本上都是和同事们在项目规格书会议上面进行的。 人们给出他们的意见，对不同的问题进行讨论，并最终得到一个由多数人同意的方案来指引我们将走向何方。
让所有人幸福的最后一步就是来一次项目规格书的总校阅。 这是一次所有同事都会参加，在此你的项目规格书将得到正式批准。 大家都坐着看项目规格书，并且如果你把你的工作已经做的足够好，人在本次会议上不应该有太多的反馈，因为他们应该已经在非正式的时候提出过了。 我们的正式项目规格书校阅是周一，祝我们好运吧！
有趣的是在我来到这里之前，我以为微软（作为一个大公司） 有着大量文档和繁琐的流程，怪异模板等。这不能责怪我，其实许多即使小于微软的公司也有那些流程。 所以当我问： "那么我应该遵循什么样的模板？ "得到的答案是"好了，这些就是你要去做的"时， 我是真的感到很吃惊。当然，基本准则还是有的，但你不一定非要遵照他们不可。 虽然他们是真的很有用，我从它们学到了很多新东西…但事实证明，每一步都严格遵守规范并不比只遵守其中正确的部分好多少。 不错，得到正确的东西，是不是太容易了--对于每一个特性的开发你必须付出很多精力以确保安全性，本地化，性能等，因为人们对这些东西是非常谨慎的。 但只要你有那些，并且大家都同意这里有那些就足够了，你就可以用你喜欢的布局或风格。 我不知道别人怎样，但我真的很喜欢这种自由！
第4步. 不断完善项目规格书
经过对项目规格书的审查，项目规格书将被打印并且文档将被标记为只读的，从此它永远不能改变… …这你只是期望罢了！ :) 规格书是一个动态的文件，并随着时间的推移，要不断改变和更新，项目经理的工作就是让其不断完善。 项目经理有责任了解每一个变化及其影响，让项目组做出正确的决定,这个是否应该改变
哇，这次已经说了很多，有那么多东西写… … 所以我想我为大家开了个头，如果大家有什么问题，不要犹豫！ 下周见！
[原文地址]: VC++ Performance Improvements in VS 2008
[原文发表时间]: Wednesday, October 10, 2007 5:59 PM
几个星期前，我在博客中谈到了Visual Studio 2008中的性能改进。有好几个人回应，问我更多关于Visual C++中这些方面的增强。
虽然那篇关于性能改进的博客着重提到了Visual C++团队完成的文件级并行生成，和增量生成本机/托管混合的项目，在VS 2008的VC++中仍然有其他一些我认为值得一提的方面。因此，现在就让我们开始吧：
· 编辑器响应 – 更新智能感应、显示QuickInfo工具提示，以及处理自动完成请求，这些操作不会降低编辑器的使用体验。
· “转到定义”方面的改进 – “转到定义”功能所需的时间有大幅度的下降。一位客户报告说原本2分钟的延迟如今被降到了10到20秒。
· 加载解决方案的性能 – 加载庞大的Visual C++解决方案的时间变得好得多。一些客户报告说其速度提升了25%到70%。
· 项目中的文件查找 – 在几个方面提供了改进，如在项目中添加文件、改变配置，等等。
· 改变配置的选项 – 对诸如添加一个包含目录或改变活动配置等选项， 在庞大的解决方案中更改它们变得比以前要快得多。
· 减少了对CPU的消耗 – 我们现在处理低优先级的后台项（如智能感知填充）所占用的CPU时间减少了20%。
我真的很希望所有这些工作会为C++开发人员提供一个显著增强的IDE体验。Visual C++团队已经在为下一个主要版本的Visual C++努力工作，并希望能在将来解决更多的有关性能和可缩放性方面的问题。同样的，对于那些在Visual C++ 2005上工作的人，该团队将会为该版本发布一个补丁来应用上述这些修改。
Namaste!
[原文作者]：Jared Parsons
[原文链接]：Closures in VB: Part 1
我叫Jared Parsons，是微软ＶＢ 编译和调试组的软件开发人员。我为ＶＢ ９.０开发的一个新特性叫做“ｌｅｘｉｃａｌ ｃｌｏｓｕｒｅ支持”。这个特性是对ＶＢ语言的一个重要扩充，因此我将通过几篇博客来解释这一特性是如何影响你的代码。
ＬｅｘｉｃａｌＣｌｏｓｕｒｅｓ（通常被简称为Ｃｌｏｓｕｒｅｓ）是Ｖｉｓｕａｌ Ｂａｓｉｃ ９．０几个新特性的内在支持，是Ｌａｍｂｄａ和查询表达式的内在实质。我将针对ＶＢ ９.０的Ｃｌｏｓｕｒｅｓ工作机制，局限性以及使用时易犯的错误将做系列性介绍。
首先，我们从一个基本的结论：什么是ｃｌｏｓｕｒｅ开始说起吧。在Ｗｉｋｉｐｅｄｉａ的定义是“．．．用于关联方法与环境的语法概念．．．”，但我更喜欢这样来描述它：一个Ｃｌｏｓｕｒｅ是一个特性，该特性允许用户从多个函数访问某一个环境（局部变量，参数和方法）。举例说明可能更易说明清楚：）
Class C1
Sub Test()
Dim x = 5
Dim f = Function(ByVal y As Integer) x + y
Dim result = f(42)
End Sub
End Class
在这段代码中，包含了一个Ｌａｍｂｄａ表达式。它有一个方法参数并将这个参数与“Ｔｅｓｔ”的局部变量做累加。在VB中，Ｌａｍｂｄａ表达式被作为函数来实现的（C#也一样）。所以，现在我们有2个方法，它们是“Test”和“f”方法。“f“方法将访问“Test”方法的局部变量x。closure将在这里发挥其功效了。Closures负责使变量x在同一个进程中对于2个方法都可用（这被称为“提升变量”）。
要做到这点，编译器将执行4个步骤的操作：
1. 创建一个类，用于包含x以便在2个方法之间共享这个变量。这里，这个类称为“Closure”
2. 编译器将在这个“Closure”类中为Lambda表达式创建一个新方法。这里，这个方法名叫“f”。
3. 编译器将在“Test“方法内部创建一个该“Closure”类的实例
4. 在“Test“方法中，将所有对于x的访问都重新改写为访问Closure类的成员变量x.
Class Closure
Public x As Integer
Function f(ByVal y As Integer) As Integer
Return x + y
End Function
End Class
Class C1
Sub Test()
Dim c As New Closure()
c.x = 5
Dim f As Func(Of Integer, Integer) = AddressOf c.f
Dim result = f(42)
End Sub
End Class
现在，两个方法都可以共享变量x了。同时，用户也无需了解任何有关编译器实际产生的代码。你可以从这个简单例子中了解到closure和所有其它VB9.0新特性（类型推断，Lambda表达式）是如何为你节省代码量的了。
注意：这个例子只是模拟了当使用Closure时编译器所产生的代码，但是实际生成的代码却看起来不是这么“优雅”，反而还用了许多难以理解的名字，如“$Lambda_1”等。
下次，我将深入地阐述一些closure更多的使用（多变量，方法访问，术语等）。
Jared Parsons
AbstractRecord这个名字不是很好,因为我不是太喜欢AEIOU开头的名词.
所以我选择了一个在google上,记录很少的名字,作为这个数据库访问框架的名字:RuntimeEntity
这个框架远在8月份就已经完成了一大半.然后就停止了.因为这段时间无论是工作还是生活,都有更加重要的事情要做.
这个星期将完成那些重要的事情,我会用业余的时间,整理一下RuntimeEntity,然后发布一个预览版本.
这次写BLOG,完全是受微软ASP.NET MVC的刺激.
微软的新的MVC框架, 似乎抛弃了ASP.NET控件,抛弃了ASP.NET AJAX.
回归到纯粹Render HTML的地步.我完全无法理解微软的这个做法.
当然,在那个MVC中,程序员仍然可以用XmlHttpRequest,或者其他封装好的框架去进行AJAX,
但是ASP.NET AJAX呢?没有回发,这不止否认了ASP.NET AJAX,甚至还否认了ASP.NET本身.
微软这么大的公司,难道就没有一条兼容控件和ASP.NET AJAX的做法吗?
甚至沦落到被人骂是抄袭也在所不惜? 新的MVC框架出来了对ASP.NET又有什么意义?
为了变相承认,ASP.NET的控件模式已经不适合WEB的发展了?
请大家宽恕我对MS这么严厉的指控. 我的目的纯粹是想突出我的MVC框架的特色 : 支持控件的模板引擎．
其实当初, 我做的不是MVC, 而只是需要实现一个模板引擎, 用于把视图分离出来, 方便美工.
和网上的其他模板引擎是类似的, 利用PropertyBag和后期绑定, 把内容显示出来.
不同的地方只是语法方面很针对美工的编程水平, 做到条件和循环语句非常简单和适合WYSIWYG.
但是我把我的设计推荐给老板时, 一下就被否决了 : ASP.NET控件怎么办 ?
是的. 如果一个新的东西, 抛弃了太多成熟的技术, 那么固然这个新东西的设计可以更加自由.
但是这个新的东西, 能让人接受吗? 如果微软做一个, 那么依然会有很多人追捧. 再难也会有人接受.
但是像我这样微不足道的人, 要推广自己的技术, 就不是那么简单了.
就像MS内某位语言大师说的一样, DotNet在设计的时候, 为了兼容老的程序, 为了和不同程序之间的整合,
提供了很多"救生圈". DotNet的Interop就是一个很好的例子.
当我做RuntimeEntity的时候,提供了SQL语句的支持,就有人质疑了.
要分清楚的是,搞科研和搞工程是2回事.
现在我要做的东西,一定要是一种过渡的方案,既提供新的功能,又要和老功能兼容.
综上,我对我的模板引擎进行了革新. 让它支持ASP.NET的Control,Postback和AJAX.
其实其中的原理, 是非常简单的. 换个说法, 如果把这个引擎,说成是 "Layout", 我想会更加容易让人理解.
看看传统的ASP.NET页面 :
Test.aspx:
<table>
<tr><td>Username:</td><td><asp:TextBox runat=server ID=Username></td></tr>
<tr><td>Password:</td><td><asp:TextBox runat=server ID=Password></td></tr>
<tr><td> </td><td><asp:Button runat=server ID="LoginBtn" Text="Login"></td></tr>
</table>
新的Layout方案:
Test.aspx:
<asp:TextBox runat=server ID=Username>
<asp:TextBox runat=server ID=Password>
<asp:Button runat=server ID="LoginBtn" Text="Login">
Test.view.html:
<table>
<tr><td>Username:</td><td>{#render Username}</td></tr>
<tr><td>Password:</td><td>{#render Password}</td></tr>
<tr><td> </td><td>{#render LoginBtn}</td></tr>
</table>
新的方案把一个ASPX文件, 分割出另外一个html,用于装载Layout.
可以看到的是, 新的Test.aspx本身,已经完全没有排版了.
里面纯粹就是放置大量程序用到的控件.
而在Test.view.html,则定义了这个页面的布局.
把控件Render到Template中,就是这个MVC方案兼容ASP.NET的核心思想.
做到这一步,这个MVC框架就和其他的纯粹生成HTML的框架完全不同了.
1. 如何支持MasterPage?
Test.view.html的输出过程是这样的:
Page.Render -> MasterPage.Render -> MVC.Render -> 整合Test.view.html+控件
也就是说,这个模板的输出目标, 不是Response, 而是控件Render过程中的一个部分.
这个部分的内容被MasterPage包围着, 所以能很方便地应用上MasterPage.
2. 如何做到回发?
回发和回发后调用控件的事件,是ASP.NET最重要的思想. 也是我不能离开ASP.NET的原因.
其他的所谓[ControllerAction],都不会比这个方便.因为ViewState能传递很多东西,而QueryString不能.
就如MasterPage的流程一样,控件被Render出去后,是和ASP.NET的回发机制兼容的.
当页面回发时,ASP.NET的其他基础流程依然能正常运作.
换个角度来说,这个MVC框架处理的只是Render的过程,改变了控件在浏览器上的位置.
这完全不会对ASP.NET的页面生命期造成任何影响.
3. 如何支持ASP.NET AJAX?
ASP.NET AJAX不愧是一种优秀的局部SmartNaviagtion方案.
它让程序员不需要花精力到DHTML中就能实现界面的局部刷新.
它的实现的机制,是通过拦截Page的Render过程,提取需要刷新的内容来返回给客户端.
这样一来,它就和我的MVC冲突了 : 2个都尝试拦截Render过程的东西, 又怎能放在一起工作 ?
这个MVC能支持AJAX的原因是, MVC拦截的不是Page,而只是内部一个控件的Render过程.
过程是 : AJAX-Page.Render -> Form.Render -> UpdatePanel.Render -> MVC.Render
可以看到的是, MVC.Render的过程, 是被包在UpdatePanel的Render里.
所以MVC生成的内容, 能够通过AJAX发送到客户端, 更新客户端的HTML.
---
其实这帖与其说是介绍帖,还不如说是技术研究帖.
希望能给各template的开发者一个新的思路.
【原文地址】 Tip/Trick: Building a ToJSON() Extension Method using .NET 3.5
【原文发表日期】 Monday, October 01, 2007 10:33 PM
今年早些时候，我通过blog介绍了 C# 和 VB 语言的一项新的扩充特性"扩展方法"。
扩展方法让开发者可以向已有的 CLR 类型的公共契约中添加新的方法，而不需要子类化或重新编译原有的类型。通过这种做法，可以使很多有用的应用场景成为可能（包括 LINQ）。同时，扩展方法也可以用来非常方便地向代码中添加"语法糖"。
过去几个月，我一直在准备一些很酷的扩展方法的清单，并计划在有空的时候实现它们（不确定何时...但至少我还能从这些想法中获得乐趣）。在上述清单中有两个扩展方法的应用场景，分别是用于为任意 .NET 对象自动生成JSON (JavaScript Object Notation)或 XML 序列化字符串的。
简单场景：ToJSON() 扩展方法
假设我有一个 Person 类定义如下（注意：我使用了 自动属性的新特性来实现）：
接下来，我就可以初始化一系列 Person 对象的集合，然后只需调用 ToJSON() 扩展方法，就能得到表示该集合内容的 JSON 字符串。如下所示：
这和 .NET 中内建的，Object 类的 ToString() 方法调用方式很相似 —— 只是生成的结果是表示集合内容的 JSON 格式的字符串而已。然后我们就可以在 AJAX 场景的客户端使用它：
注意：点击上图中调试器的放大镜图标，可以打开"文本视图(Text Visualizer)"，能更方便的查看 JSON 序列化字符串：
接下来，这个字符串格式在客户端可以用 JavaScript 来实例化为合适的 JavaScript 对象，用于表示我的集合内容（注： ASP.NET AJAX 有一个内建的 JavaScript 库支持这些特性）。
实现 ToJSON 扩展方法
实现一个基本的 ToJSON() 扩展方法很简单。只要使用 System.Web.Script.Serialization 命名空间下的 JavaScriptSerializer 类即可，然后象下面所示的那样定义两个扩展方法。其中一个方法用于对目标对象图（object graph）进行"深"的序列化，而另一个方法则是一个重载的版本，它允许你指定序列化的深度（比如：ToJSON(2) 只序列化 2 个层次的深度）。
注意，上面的 ToJSON() 扩展方法只是针对 "Object" 类型而定义的——这意味着它可以被用于 .NET 中的任何类型（不限于集合）。也就是说，我们不仅能对上述集合调用 .ToJSON() 方法，还可以对单独的 Person 对象调用 ToJSON() 方法，或者任意其他的 .NET 类型都可以。
要使用上述扩展方法，只需在程序的顶部添加如下命名空间的引用即可：
然后 VS 2008 就可以为任意对象提供针对这些扩展方法的代码自动完成和编译时支持功能：
注意：除了 JavaScriptSerializer 类之外，.NET 3.5 还包含一个新的new System.Runtime.Serialization.DataContractJsonSerializer class 类 ，你也可以用它来做 JSON 序列化/反序列化的工作。
小结
希望以上的例子能给你一个使用扩展方法来封装功能的示例。下次希望我们一起来看一些好的工具库，用于提供类似有用的扩展方法的功能。
我非常想看到其他关于可复用的扩展方法使用场景的建议（请通过这篇帖子的评论来建议）。然后我们可以琢磨出，如何创建一个好的 CodePlex 项目，来把这些方法捆绑到一个库中以便利用。
希望这篇帖子对你有用，
Scott
注：请通过我的 技巧/诀窍 和教程页面 找到我写的更多有用的 ASP.NET 和 .NET 的帖子。
双方前锋紧紧地站在一起，裁判哨声响起，球被掷出，双方球员奋力拼搏，反复地冲刺，竭尽全力向自己的目标冲去。这是英式橄榄球中Scrum的场景。然而这样的活动，却被Ken Schwaber和 Jeff Sutherland巧妙地借助隐喻的方式引入到敏捷项目管理中，仔细思索，却又如此的恰如其分。在橄榄球运动中，固然需要强健的体魄与迅捷的速度，但更重要的却是组织、协作、交流，以及一位优秀的指挥官。虽然二者的方式不同，然而赢得比赛与成功交付产品的目标其实是完全一致的。
Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代、递增的软件开发过程。Scrum方法最初实践于Easel公司，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。作为一种项目管理方法，Scrum与其它方法颇有不同之处，规则与名称也自成一套体系。在Scrum管理活动中，包含三种不同的角色：Scrum Master，Product Owner，Team。Scrum的每一次迭代被称为Sprint，意为“冲刺”，生动形象地展现了项目开发活动的迭代过程。Scrum将功能需求称之为Product Backlog，它们通常是由Product Owner提出。Product Backlog会在Scrum Master主持的Sprint Planning Meeting中确定，并在确定了Sprint之后，形成Sprint Backlog。Scrum非常重视团队成员的交流，除了Sprint Planning Meeting之外，还要求召开Daily Scrum Meeting，以及Sprint Review Meeting与Sprint Retrospective Meeting。
虽然Scrum从名词的定义上来看，显得有几分离经叛道，但其本质仍然秉承了敏捷开发思想。重视成员的交流、功能需求的确定、迭代版本的交付、项目风险以及产品质量的控制。Scrum提供了一种经验方法，它使得团队成员能够独立地、集中地在创造性的环境下工作。Scrum过程是敏捷的、自组织的，产品的开发则是增量的迭代交付方式。
《SCRUM敏捷项目管理》一书全面细致地介绍了Scrum方法。作为Scrum的创始人与倡导者，作者Ken Schwaber将自己多年以来实施Scrum方法的经验、体会、教训浓缩在这本仅有163页的薄薄小书中，真可谓是字字珠玑。全书只有9个篇章，却涵盖了Scrum的方方面面，包括Scrum方法概述，Scrum角色的职责，如何从混沌中提炼Product Backlog以及如何划分Backlog的优先级，如何制定Scrum项目计划，跟踪项目计划的执行，以及如何在大规模项目中应用Scrum方法。书中的附录A更是Scrum方法的精华，总结了实施Scrum方法必须遵循的基本原则。
全书并没有长篇大论的理论分析与描述，而是通过一个个真实典型的项目案例，逐步为我们展现了Scrum的适用场景与实施细则。以实践指导实践，是本书最大的亮点，从而使得本书摆脱了通常所谓的项目管理书籍的那种沉闷与枯燥，以及空中楼阁般的不切实际。这得益于作者娓娓道来的深厚文字功底，更重要的是作为敏捷联盟的创始人之一，作者深谙敏捷之道，能够目光敏锐地发现传统项目开发的瑕疵；而作为Scrum的倡导者，对于Scrum方法的实施早已达到游刃有余的境界。因此，本书可以说是ken的厚积薄发之作。
Ken善于以案例启发读者。Scrum提供了一种经验方法指导团队成员独立、高效地完成项目开发，而本书则以项目实践指导读者从阅读中获取经验。全书的每一章几乎都提供了“Lesson Learned”小节，从而加深读者对Scrum方法的理解。
理解Scrum方法并不困难，最大的困难在于如何正确地在项目开发中应用Scrum方法。即使是富有经验的Scrum Master，在面对不同的场景，也需要做出不同的抉择。正如书中所述：“The ScrumMaster applies Scrum theory to projects with different types and degrees of complexity.”项目的类型不同，复杂度不同，则应用的Scrum方法就会有所区别。
以书中列举的Tree公司的项目为例，就需要成立XML Team，WebPub Team以及多个Journal Team。而在Journal Team中，Scrum Master并没有固执地按照Scrum原则安排7个成员，而是由9个成员组成，其中包括了兼职的XML成员与WebPub成员。
在MegaFund项目中，为了合理地分解任务与团队，在提炼Product Backlog时，则将非功能性需求的优先级提高到功能性需求之前。这样的调整，同样是根据项目的特点而定。
Scrum方法的优势在于它的设计自始至终具有很强的适应性。如何在自己的项目开发中准确地应用Scrum，让自己成为合格的ScrumMaster，让团队的需求分析师或者客户成为合格的Product Owner，让自己的团队成为合格的Scrum Team，相信你从本书能够找到扣开Scrum之门的钥匙。本书无法使你在一夜之间就成为一名优秀的Scrum大师，但本书作者Ken Schwaber却可以给你高屋建瓴般的整体指导，使你迅速成长。毫无疑问，《SCRUM敏捷项目管理》已经给你指出了一条掌握Scrum项目管理的终南捷径了。
【原文地址】October 8th Links: ASP.NET, ASP.NET AJAX, Silverlight, and .NET
【原文发表日期】 Monday, October 08, 2007 11:14 PM
这是我的链接系列的最新篇。也请参阅我的ASP.NET 技巧，诀窍和教程网页里我以前写的众多很受欢迎的文章的链接。
ASP.NET
ASP.NET AJAX
Silverlight
.NET
希望本文对你有所帮助，
Scott
上个月，NUnit的作者James Newkirk宣布推出了新的单元测试框架，xUnit.net。他列出了从以前的单元测试框架得到的教训后所做的改动：
- 每个测试方法都对应一个新对象实例。 为提高测试的隔离性， 改变了NUnit V2.0 的做法，xUnit.net为每个测试方法生成一个新实例。具体理由参考James Newkirk的博客贴子《Why variables in NUnit [TestFixture] classes should be static? 》和MartinFowloer的讨论《JunitNewInstance》。
- 除去了[SetUp] 和 [TearDown]。 James Newkirk在名为《Why you should not use SetUp and TearDown in NUnit》的博客里讨论了跟SetUp/TearDown相关的问题，这是非常有争议的，参考该贴子里的回复。
- 除去了[ExpectedException]。 不再使用标记特性的方法，而是回到老式的JUnit Assert.Throws风格。这可以避免2个重大问题，1. 使用 [ExpectedException]的话，有可能因为错误的方法调用抛出的异常而掩盖了真实的错误。2. 允许你的测试继续遵守 Arrange-Act-Assert 模式。
- 提供了类似Aspect的功能。 xUnit.net 极大地方便了用户生成扩展特性类来把横切的关注附加到测试方法上。blogs.msdn.com的Casper示范了一个改变运行测试方法线程身份的例子。
- 减少了自定义特性的数目。xUnit.net不是靠泛滥的自定义特性，而是依赖语言特性来提供类似功能:
- 除去了[TestFixture] ，所以测试代码可以存在于任何地方。
- [Ignore]可以通过[Test]的Skip=参数来表示。
- 除去了[SetUp] 和 [TearDown]。
- [ExpectedException] 被Assert.Throws替代。
- [TestFixtureSetup] 和 [TestFixtureTearDown] 可以通过实现ITestFixture来达成。
- 添加了对测试的IDisposable支持。
xUnit.net使用了泛型来实现类安全的比较操作，譬如Equal和NotEqual，以及使用匿名代理来实现Assert.Throws。譬如，
Assert.Throws<InvalidOperationException>(delegate { operation(); }); // .NET 2.0
Assert.Throws<InvalidOperationException>(() => operation()); // .NET 3.5
xUnit.net目前只提供基于控制台的测试runner。xUnit.net还提供了很多扩展性:
Assert的扩展性。通过使用实现了IComparer<T>的自定义比较器，你可以扩展Equal, NotEqual, InRange, 和 NotInRange等概念。在Samples项目里，有2个例子，一个是做大小写不敏感的比较，另一个是只对DateTime的日期部分做比较。 测试方法的扩展性。如何运行一个测试方法的定义是可以扩展的。有2个例子，1. 在扩展DLL里，可以通过[Theory] 来实现数据驱动的测试，2. [RepeatTest]特性可以连着多次运行一个测试方法。 测试类的扩展性。如何运行一个测试类的定义是可以扩展的。 譬如在扩展DLL中，[RunWithNUnit] 特性允许你在同一个程序集中混合xUnit.net 和 NUnit 测试，然后可为任何xUnit.net runner所运行。
根据Jeffrey Palermo，在刚举行的ALT.NET大会上，Scott Guthrie 对他的团队正在开发的MVC框架做了示范，预计在今年年底推出CTP版本。其中将包括：
内在支持控制器的TDD模型 提供ASPX (不带viewstate或postback)作为视图引擎 提供了可为其他视图引擎（譬如MonoRail的)所用的hook 对控制器依赖注入的控制反转（IoC）容器的支持 提供对URL和导航的完全控制 整个过程的插拔式支持 关注分离 与ASP.NET的良好集成 同时支持静态和动态语言 具体细节参考Jeffrey Palermo这里的博客贴子。
这是个漫长，炎热的夏天，期间经历了5个项目，可谓身心俱累。
非常对不起的是，Scott的博客的翻译几乎中止了。偏偏Scott又非常多产，大概错过了40多个博客贴子，其中包括很精彩的LINQ to SQL系列，但我计划在以后陆续补全其中精彩的博客贴子。如果有谁愿意和我共同翻译的话，请与我联系，谢谢！
More Posts
Next page »