Hamilton向微软MVC团队通报了Castle团队从现实应用中获得的所有复杂和不直观的需求，并告知他们如何处理这些事情。另外他还开发了一些集成案例，作为对MS MVC可扩展性和插拔性的概念验证。

上个星期，Hamilton向微软MVC团队通报了Castle团队从现实应用中获得的所有复杂和不直观的需求，并告知他们如何处理这些事情。另外他还开发了一些集成案例，作为对MS MVC可扩展性和插拔性的概念验证。

我现在可以做到：

  • 创建对IParameterBinder的初始支持
  • 创建NVelocity视图工厂（View Factory）
  • 支持REST（支持基于接收头[accept header]的url语义和渲染）
  • 支持和Castle的DataBinder和ActiveRecordDataBinder的协同工作

我想要实现但还未能做到的功能：

  • 重用MonoRail的helpers：主要因为他们和MonoRail绑定的太紧了
  • 创建Brail视图工厂：和上面同样的原因
  • 创建一个试图工厂选择器：影响现有的测试性

目前Hamilton对MS MVC框架的做法非常满意，但是他建议社区对在年底要发布的CTP版本不要抱太大的期望：

那是因为你将要看到的是一个非常小的框架，要真正发挥作用还有许多工作要做，据MS MVC团队说这一CTP版本主要是为了获得反馈，不过，我相信接下来的版本会非常棒！

对于Castle MonoRail的未来，Hamilton说他们要等到MS MVC框架的最终版和功能集确定之后才能决定：

我真的非常期望MS MVC团队能试着支持MonoRail现在所支持的所有的东西，但是我不确定他们打算这样做。MonoRail 2.0最终结果如何取决于MS MVC框架的实现。如果最终的MS MVC非常棒，并且提供了很多功能，我会考虑放弃MonoRail 2.0。如果MS MVC最终版不是那么完美，缺少了必须实现的功能，那么MonoRail 2.0可以复用MS MVC的基础架构，以提供一些有价值的扩展。

Eleutian Technology公司的工程总监​​Aaron Jensen​​​同意Hamilton的观点，并​​建议说​​：

我想要看到的是MonoRail能变得真的像Rails。我想看到一些在MS MVC之上的实现，它们更加遵循“惯例胜于配置”的理念——包括生成器以及更多的功能。我期望它能更进一步，成为.NET社区所期望的一个真正的C# Web平台。
但是Aaron、​​​Adam Esterline​​​和其他一些人也指出了MonoRail​​对routing功能支持的不足​​：

Routing——在RoR和MS MVC中它们视Routing为一等公民。而在​​MonoRail​​​中却好像是一个附加之物。

为什么Routing这个顶级类如此重要呢？

  • DRY（别重复自己）——Routing引擎和URL生成的紧密绑定允许URL进行轻松和安全的重构；
  • 测试——在​​MonoRail​​中测试Route需要端对端（End-to-End）的测试，如果Route是顶级对象，那么就可以对它们做隔离测试。

Hamilton对Routing的问题已经进行了关注，他开发了一个​​新的MonoRail Routing引擎​​，相关的代码可以在MonoRail SVN上下载。

Ben Scheirman在他的一篇博客中讨论了​​微软技术和开源技术的话题​​，总结说“System.Web.MVC将拥有的观众数是MonoRail所无法达到的，因为很多企业巨头们已经着了微软的道，无论微软的技术是好是坏，他们都会去做，而且有许多顾问公司很坚决地工作在这个领域！”

查看英文原文：​​The Future of MonoRail in the Wake of MS MVC​​