MS MVC框架漩涡中的MonoRail未来

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

你可能感兴趣的:(MS MVC框架漩涡中的MonoRail未来)