MS MVC框架漩涡中的MonoRail未来-InfoQ

上个星期，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