原文地址：Comparing Moq to Rhino Mocks
原文发表时间：Mar 23, 2008
长期以来我是Rhino Mocks的大粉丝，乐此不疲的写关于它的文章。当Moq出现时，我一直对它无动于衷，因为我原以为lambda表达式是华而不实的。我认为如果它只是使用lambads的话，我对此不感兴趣。
幸运的是 在我的twitter圈子里有一些人一直对Moq大加赞赏。我是一个乐于承认错误的人，所以我决定找出Moq究竟好在哪里。结果发现，使用lambdas并不是Moq最优的部分。它有清晰干净的API设计以及弱的录制/回放模式.
为了更好的说明我的意思，这里有一个简单的例子，分别用Rhino Mocks和Moq写的两个单元测试方法。使用mock框架的测试，只用一个方法来建出一个接口。
[Test]
public void RhinoMocksDemoTest()
{
MockRepository mocks = new MockRepository();
var mock = mocks.DynamicMock<ISomethingUseful>();
SetupResult.For(mock.CalculateSomething(0)).IgnoreArguments().Return(1);
mocks.ReplayAll();
var myClass = new MyClass(mock);
Assert.AreEqual(2, myClass.MethodUnderTest(123));
}
[Test]
public void MoqDemoTest()
{
var mock = new Mock<ISomethingUseful>();
mock.Expect(u => u.CalculateSomething(123)).Returns(1);
var myClass = new MyClass(mock.Object);
Assert.AreEqual(2, myClass.MethodUnderTest(123));
}
注意使用Moq的测试只需要四行代码，而使用Rhino Mocks的测试需要六行。代码的行数当然不是衡量API的标准，但在这个例子中确实是这样。Rhino Mocks中多于的代码是由于需要实例化MockRepository类并调用它的RepalyAll方法。
我喜欢Moq的另外一个方面是expectations都是基于Mock自身的。即使在我喜欢上它之后，当要使用Rhino Mocks建立results/expecations时，我仍然很困惑。首先你必须使用正确的静态方法，不管是 SetupResult 还是 Expect。第二，我经常搞不清SetupResult.On和SetupResult.For.我感觉MoQ更加直观和清晰。
我要习惯于Moq的另外一个小的方面是 我一直努力将Mock本身而不是Mock.Object传到需要它的method/ctor上。当你使用Rhino Mocks创建mock的时候，你取回的是实际的类型而不是wrapper.然而，我看到了在Moq方法中使用wrapper的好处，现在非常喜欢用它。
对Moq的唯一的抱怨 是它的名字。谈论Moq的你必须说“Moq with a Q”.比起MoQ，我更喜欢MonQ.不管如何，如果那是我唯一的抱怨，那我是一个快乐的人！你可以从google Code Page 下载MoQ，了解更多。
Nice work Kzu!
附录
万一你想重建测试例子，以下是我MyClass和接口IsomethingUseful的代码。
public interface ISomethingUseful
{
int CalculateSomething(int x);
}
public class MyClass
{
public MyClass(ISomethingUseful useful)
{
this.useful = useful;
}
ISomethingUseful useful;
public int MethodUnderTest(int x)
{
//Yah, it's dumb.
return 1 + useful.CalculateSomething(x);
}
}
原文地址：A Few Notes About The MVC CodePlex Source Code Release
原文发布日期：Mar 22, 2008
Whew!在一些读者的强烈要求下（不只是Sean, Jeff向我提起过此事。）我写了一篇非MVC的文章，然后再写MVC。既然我写了那篇Pizza的文章，或许在我的善意被榨干之前，我该多写一些关于MVC的文章，然后再下定决心写一些MVC无关的东西。;)
正如ScottGu最近的文章写的，ASP.NET MVC的源代码已经在CodePlex上发布了.这件事并不想开‘开关’那样简单。在这背后，我们做了很多努力。一方面是有关的计划工作，以及Bertrand Le Roy和我的老板Simon做了很大的努力。
与此同时，计划的执行需要不同团队例如:Devs,PMs,QA已经legal(法律)团队的互相协作。为此 要感谢我们新任的PM Scott Galloway的努力。在做计划工作以及写了一篇很短的readme（我不知道怎么说）和readme（我不知道怎么说）和roadmap中，我做了一些微小的工作。多亏我们法律团队的一个同事，这次任务完成的出人意料的好。我原来以为会发生一场“战争”，但这家伙搞定了这样事，他理解我们的工作，和他工作也很轻松。
我看到了许多与此有关的问题，我在这里可以回答一些。
是不是一个在线实时更新的代码库？
不是，由于一些原因，MVC开发团队并不是直接工作在CodePlex的代码库上。一个实际的原因我们试图尽量减少对我们工作的干扰。中途改变源代码的管理库是一个很大的干扰。现在，当我们认为有值得放到CodePlex上的代码时，我们会定期的将代码上传上去。
Routing的源代码在哪里？
我在以前的文章中谈过，routing并不是MVC的一个特性，所以它并不包括在MVC代码里，它将是.Net Framework的一部分，因此它的代码也将会像其他的.NET Framework 代码 那样开放.包含在CodePlex是很好的，但就如我以前说的 慢慢来。
单元测试在哪里？
等等！你是说哪里没有单元测试吗？那我要与Scott谈一些。哈哈，我是开玩笑的。我们打算把单元测试放到那里，但是当前的测试要依赖一些内部工具，这些工具是我们不想发布的。我们希望使用一些我们能分发的工具来重写这些单元。
下一个在CodePlex上更新是什么时候？
就如我提到的，我们有东西的时候，我们就会更新源代码。希望尽多尽早。我们拭目以待。
作为一个团队，我们对此很激动。我在想开发员对这种程度的开放度是否会感到坐立不安。当然，任何人都可以看到这些代码以更多的了解.NET Framework，但是 这些代码已经被发布。这些都是早期工作中的。你是否能够想象你的老板把你的工作进程全都公布出来，让所有人来进行评判（如果你是一个全职的开源程序员就不用回到了）。;)我也不一定会让所有人看我早期使用.net技术的代码。
幸运的是，我们团队的开发人员因为这样的开放性获得了许多好处。它使我们与客户之间的协作更加紧密并且创建一个更为紧密的反馈系统。我有信心，我们在最终的产品里会完成所有的设计的功能。当然在它开放的时候会有一些限制。我曾试着建议我们更加开放并把我们的信用卡号公布在哪里，但那并不可行。
【原文地址】: Is Pizza Brain Food?
【原文发表时间】: Mar 21, 2008
在一个临时的住处住了两个月之后，我和我的家人搬到了新的住处。搬家的一大好处是，它让你感到又像过了一次圣诞。”Oooh! 看那些我要拆封的箱子。Hey！我有一个像这样的音响!”
我似乎要被我那些拆封的东西分散注意力了。比如，我发现一些我大学里的数学书。我就开始想到这些Complex Analysis,抽象代数和数论，他们看起来像天书一样。
艺术家和作家都是拥有创造性的。这就是人们称他们为创造类型的原因。而数学家却经常被错误的描绘为缺乏幽默感，只会动笔，毫无创作的类型。这并不是事实，一些数学家现在已经使用电脑了，也喜欢说这样的笑话：“Can you prove that the integral of e to the x is equal to f sub u of n?”如果我把这个方程写出来，那这个笑话就变的很明显了。
∫ex = fu(n)
Hey,我并不是说数学家很有幽默感。事实上认为数学家缺乏创造力的人，是从来不重视数学的人的想法。一旦你接触了abstract algebra（抽象代数）, number theory（数论）, non-Euclidean geometry（非欧几里德几何），等等… 你就会开始猜想这个领域的巨人们是否会吸食一些什么来帮助想出这些理论。
我觉的proof of Fermat’s Last Theorem的证明（据报道经历了连续7年的工作）或许世上无人能明白。就像一副现代艺术博物馆里的抽象画一样。但…似乎是我貌似有点离题了….
数论是我当时最喜欢的课，所以我想我可以坐下来翻开这个书本，看看我能明白里面的问题，甚至能取得一些进步。
No Dice.
在我读大学的时候 我能弄明白这个问题，但现在尽管我长大了而且更聪明了，要理解这个问题却很慢。即是我曾经已经弄明白过了。然后我开始思考？现在的我和大学时代的我有什么不同呢？这打击了…
Pizza Consumption!
考虑了一秒。他们经常说程序员是把咖啡变成代码的机器。我想大学数学系里的学生是否是把披萨变成解决问题集的机器？那那些早期的白手起家的神话又是怎样呢，他们是从一小群大学生喝个百事吃着披萨开始的， 最终却成为千万富翁？批萨是共同点。
我想我说到了一些事情。也许批萨是益于大脑的食物。不知道是不是Mozzarella(意大利干酪之一) 或者 Pepperoni (烤胡椒香肠)起的作用.当然我的现在的问题是大学是很久以前的事情了，而批萨是否是益于大脑的食物，只是我无聊的猜测。这是一个既定的事实，比萨饼肯定是肠道的食物。是利于思考的食物。
【原文地址】：Url Routing Debugger
【原文发表时间】: Mar 13, 2008
在Mix会议上，Scott Hanselman’s演示了一个简单的route测试程序（route tester），我很快的把他们整理出来了。
_3.png)
这个工具会显示当前地址栏中请求地址里存在的Route数据内容（页面里的Route Data）。因此你可以在地址栏中输入各种Urls来观察它匹配了哪一个路径。在页面底部，显示了你的程序中所有被定义的route列表。它可以让你看到当前的URL匹配哪个你定义的route。
这个工具的用处在于，有时候你希望的匹配路径却被其他的路径定义所代替。它可以向你展示出发生了这种情况。但是，这个工具并没有提供任何关于为什么发生这种情况的信息。希望我们以后能做更多的事情来改善这个。
要使用这个工具，只要下载这个zip文件，然后把dll文件放到你的程序的Bin目录里，再在Global.asax.cs文件的Appliation_Start函数里添加一行代码（黑体字的）。
protected void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);
}
它会使用DebugRouteHandler来更新那些你的应用中所有的route处理程序（IRouteHandler），这些route处理程序原本是为了处理程序中每个不同的route特别定义的。它在最后添加了一个catch-all route，以确保这个调试器总能匹配对这个应用程序的所有请求。
我也会发布所有的代码（使用“所有”听起来有很多代码，其实代码不太多）它包含了一个使用这个route tester 的demo程序。这个东西对你是否有用，请告诉我一声。
【原文地址】：Thoughts on ASP.NET MVC Preview 2 and Beyond
【原文发表时间】: Mar 10, 2008
【译者注：由于是刚开始做翻译，很多语句和单词翻译的很有问题，有些单词还不会翻译比如文章中出现的DropDown，hoopla等，所以现在的文章是中英文对照着发的，如果你看到哪里不爽，或者哪里变扭 指正，我会不断改进，不断学习的。谢谢】
At this year’s Mix conference, we announced the availability of the second preview for ASP.NET MVC which you can download from here. Videos highlighting MVC are also available.
在今年的Mix会议上，我们发布了asp.net mvc预览第二版，你可以在这里下载到，视频可以在这里下载。
Now that I am back from Mix and have time to breathe, I thought I’d share a few (non-exhaustive) highlights of this release as well as my thoughts on the future.
现在开完了Mix会议，我有时间稍作休息，我想分享一些这一版本的亮点，以及我对未来的一些想法。
New Assemblies and Routing
新的Assemblies 和 Routing
Much of the effort and focus of this release was put into routing. If you’ve installed the release, you’ll notice that MVC has been factored into three assemblies:
这个版本的大多数精力都放在routing上。如果你安装了这一版本，你会发现MVC已经被分解成下面三个集合：
· System.Web.Mvc
· System.Web.Routing
· System.Web.Abstractions
The key takeaway here is that MVC depends on Routing which depends on Abstractions.
这里关键点是：MVC依赖Routing,Routing依赖Abstractions（译注：takeaway不知如何翻译）
MVC => Routing => Abstractions
Routing is being used by another team here at Microsoft so we worked on making it an independent feature to MVC. MVC relies heavily on routing, but routing doesn’t have any knowledge of MVC. I’ll write a follow up post that talks about the implications of that and how you might use Routing in a non-MVC context.
微软另外一个工作组也正在使用Routing,因此我们要做的工作是把Routing变为MVC一个独立的特性 。MVC主要依赖于routing工作，但routing本身不使用到任何MVC的内容。以后我会写一篇文章专门来讨论这个问题以及如何在没有MVC的背景下使用Routing。
Because of the other dependencies on Routing, we spent a lot of time trying to make sure we got the API and code correct and making sure the quality level of routing meets an extremely high bar. Unfortunately, this investment in routing did mean that we didn’t implement everything we wanted to implement for MVC core, but hey, it’s a preview right? ;)
由于Routing还有其他的附属物，我们花了很长时间来确保我们得到了正确的API和代码并确保routing的质量达到一个相当高的水平。不幸的是，我们在routing里的努力并没有实现我们想为MVC核心实现的所有东西，但是，这幸好这只还是个预览版 ;)。
CodePlex Builds
At Mix this year Scott Hanselman’s gave a great talk (IMHO) on MVC. One thing he announced during that talk is the vehicle by which we will be making the MVC source code available. Many of you might recall ScottGu’s recent roadmap for MVC in which he mentioned we would be making the source available. At Mix, Scottha announced that we would be deploying our source to CodePlex soon.
在这次Mix会议上，Scott Hanselman’s 做了一个关于MVC的演讲(IMHO)。其中他宣布了我们将开放MVC源代码的载体，你们也许会联想到ScottGu’s最近的MVC路线图，这路线图里他提到了我们将要开放源代码。在Mix会议上，Scottha宣布我们将很快把源代码放到CodePlex上。
Not only that, we hope to push source from our source control to a CodePlex Project’s source control server on a semi-regular basis. These builds would only include source (in a buildable form) and would not include the usual hoopla with associated with a full Preview or Beta release.
不仅如此，我们希望在半规则基础(??semi-regular basis不知如何翻)上，将源代码从我们的代码管理器放到CodePlex项目的代码管理服务器上。这些builds仅包括源代码（以可编译的形式），不包括一般的与完整预览或beta版相关联的hoopla(？)
How regular a schedule we keep to remains to be seen, but Scott mentioned in his talk around every four to six weeks. Secretly, between you and me, I’d love to push even more regularly. Just keep in mind that this is an experiment in transparency here at Microsoft, so we’ll start slow (baby steps!) and see how it progresses. In spirit, this would be the equivalent to the daily builds that are common in open source projects, just not daily.
怎样制订日程现在还不知道，但Scott在他的谈话中提到，大约每隔四至六星期上传一次。悄悄的告诉你，我将更频繁的上传。只要记住，这是微软对于透明性开发的一次尝试，所以我们将有一个缓慢的开始来看一下它是怎样进展的。在精神上，他与开源项目中常见的每日编译是相同的，只是它不是每天编译。
Unit Test Framework Integration
单元测试框架的整合
In a recent post, I highlighted some of the work we’re doing around
integrating third party unit testing frameworks.
在最近的一篇文章中，我重点讲了我们正在做的关于整合第三方单元测试框架的一些工作。
I’ve been in contact with various unit testing framework developers about integrating their frameworks with the MVC project template. I’m happy to see that MbUnit released updated installers that will integrate MbUnit into this dropdown. Hopefully the others will follow suit soon.
我已经与许多单元测试框架的开发者进行了联系，讨论把他们的框架与MVC项目模板整合。很高兴看到MbUnit released updated installers将把MbUnit整合进这个dropdown(?).希望其他人也能很快这样做。
One interesting approach I should point out is that this is a great way to integrate your own totally tricked out unit testing project template complete with your favorite mock framework and your own private assembly full of your useful unit test helper classes and methods.
我想指出的很有趣的一点是，将你们自己完全独立的单元测试项目模板，与你们喜欢的模拟框架以及装满了有用的单元测试帮助类及方法的私有集合完全整合在一起，这是一个非常好的方法。
If you’re interested in building your own customized test framework project which will show up in this dropdown, Joe Cartano of the Web Tools team posted an updated streamlined walkthrough on how to do so using NUnit and Rhino Mocks as an example.
如果你对建立自己定制的测试框架项目（将出现在这个dropdown里）有兴趣，怎样来做，web工具工作组里的Joe Cartano写了一篇updated streamlined walkthrough，它是以使用NUnit和Rhino Mocks为例的
Upcoming improvements
待改善之处
One area in this preview we need to improve is the testability of the framework. The entire MVC dev team had a pause in which we performed some app building and uncovered some of the same problems being reported in various forums. Problems such as testing controller actions in which a call to RedirectToAction is made. Other problems include the fact that you need to mock ControllerContext even if you’re not using it within the action. There are many others that have been reported by various people in the community and we are listening. We ourselves have encountered many of them and definitely want to address them.
在这预览版中 我们需要改进的一个地方是框架的可测试性，在我们做一些项目building时,整个MVC开发团队有了一些中断，发现了一些在许多论坛被提出的同样的问题。类似于调用RedirectToAction出现的testing controller actions问题。其他的问题包括这样一个事实：你需要模拟ControllerContext，即使你不在action中使用它。社区还有许多人报道了一些其他的问题，我们正在听取。我们自己也遇到了其中的一些问题，当然也想解决他们。
Experiencing the pain ourselves is very important to understanding how we should fix these issues. One valuable lesson I learned is that a framework that is testable does not mean that applications built with that framework are testable. We definitely have to keep that in mind as we move forward.
To that end, we’ll be applying some suggested improvements in upcoming releases that address these problems. One particular refactoring I’m excited about is ways to make the controller class itself more lightweight. Some of us are still recovering from Mix so as we move forward, I hope to provide even more details on specifically what we hope to do rather than this hand-waving approach. Bear with me.
去亲身体验这种痛苦能有助于我们更好地解决这些问题。我得到的一个有价值的教训是：一个可测试的框架并不是指那些用框架所建立的程序是可测试的。当我们继续工作时我们必须记住这一点。最终，我们会发行一个解决这些问题的版本，这一版本里会应用一些大家提出的改善的意见。尤其另我激动的是使controller类自身变的更加轻量级。我们的一些人在Mix后还在休息阶段，所以当我们继续工作时，我希望提供我们想做的东西的更多的具体细节，而不是笼统地说一下。Bear with me.
During this next phase, I personally hope to have more time to continuously do app building to make sure these sort of testing problems don’t crop up again. For the ones that are out there, I take responsibility and apologize. I am a big a fan of TDD as anyone and I hate making life difficult for my brethren. ;)
在下一阶段，我个人希望有更多的时间继续做app building,来确保这些测试问题不再发生。对于已经发生的问题，我有责任并且向大家道歉。我和任何人一样我也是TDD的大粉丝，我讨厌把生活变的麻烦。；）
RTM
When do we RTM? This is probably the most asked question I get and right now, I don’t have a good answer. In part, because I’m still trying to sort through massive amounts of feedback regarding this question. Some questions I’ve been asking various people revolve around the very notion of RTM for a project like this :
什么时候RTM？这也许是我被问及的一个最频繁的问题，但我目前还没有一个确定的答案。一方面，因为我一直在对关于这个问题的反馈进行归类。我被问及的一些问题，许多人把RTM定义为这样一个项目：
· How important is RTM to you?
· RTM对你来说有多重要？
· Right now, the license allows you to go-live and we’ll provide the source, is that good enough for your needs?
· 目前，我们使用go-live协议，我们会提供源代码，这足够满足你们的需要了吧？
· Is it really RTM that you want, or is it the assurance that the framework won’t churn so much?
· 你们是真的需要RTM吗？或者她只是用来确保框架不会乱改？
· What if we told you what areas are stable and which areas will undergo churn, would you still need the RTM label?
· 如果我们告诉你哪些区域是稳定，哪些区域会有变动，你还会需要RTM标志吗？
· Is there a question I should be asking regarding this that I’m not? ;)
· 这句就不翻译了 J
I do hope to have a more concrete answer soon based on this feedback. In general, what I have been hearing from people thus far is they would like to see an RTM release sooner rather than later, even if it is not feature rich. I look forward to hearing from more people on this.
我确实希望在这个反馈的基础上有更加具体的回答，总之，到目前我一直听到是：大家希望看到RTM版尽快发行，即使它的特性不够丰富。我期待更多人对于此的想法。
Closing Thoughts
最后的想法
In general, we have received an enormous amount of interest and feedback in this project. Please do keep it coming as the constructive feedback is really shaping the project. Tell us what you like as well as what is causing you problems. We might not respond to every single thing reported as quickly as we would like to, but we are involved in the forums and I am still trying to working through the massive list of emails accrued during Mix.
总之，我们收到无数了对于这个项目的兴趣以及反馈。请继续，因为建设性的反馈的确正在塑造这一项目。告诉我们,你们喜欢的，和导致问题的东西。我们可能无法如愿尽快回应每一个反馈，但是我们关注着论坛，我仍将处理由于Mix会议所积累的邮件。