本文共 1400 字，大约阅读时间需要 4 分钟。
我现在可以做到：
- 创建对IParameterBinder的初始支持
- 创建NVelocity视图工厂（View Factory）
- 支持REST（支持基于接收头[accept header]的url语义和渲染）
- 支持和Castle的DataBinder和ActiveRecordDataBinder的协同工作
我想要实现但还未能做到的功能：
- 重用MonoRail的helpers：主要因为他们和MonoRail绑定的太紧了
- 创建Brail视图工厂：和上面同样的原因
- 创建一个试图工厂选择器：影响现有的测试性
那是因为你将要看到的是一个非常小的框架，要真正发挥作用还有许多工作要做，据MS MVC团队说这一CTP版本主要是为了获得反馈，不过，我相信接下来的版本会非常棒！
我真的非常期望MS MVC团队能试着支持MonoRail现在所支持的所有的东西，但是我不确定他们打算这样做。MonoRail 2.0最终结果如何取决于MS MVC框架的实现。如果最终的MS MVC非常棒，并且提供了很多功能，我会考虑放弃MonoRail 2.0。如果MS MVC最终版不是那么完美，缺少了必须实现的功能，那么MonoRail 2.0可以复用MS MVC的基础架构，以提供一些有价值的扩展。
我想要看到的是MonoRail能变得真的像Rails。我想看到一些在MS MVC之上的实现，它们更加遵循“惯例胜于配置”的理念——包括生成器以及更多的功能。我期望它能更进一步，成为.NET社区所期望的一个真正的C# Web平台。 但是Aaron、 和其他一些人也指出了MonoRail ：
Routing——在RoR和MS MVC中它们视Routing为一等公民。而在 中却好像是一个附加之物。 为什么Routing这个顶级类如此重要呢？
- DRY（别重复自己）——Routing引擎和URL生成的紧密绑定允许URL进行轻松和安全的重构；
- 测试——在中测试Route需要端对端（End-to-End）的测试，如果Route是顶级对象，那么就可以对它们做隔离测试。