这两天看了一本书《Grails权威指南》,看了这个Java上Rails框架,其中有两条设计理念:
1、make simple thing easy and make complex possible -让简单的事情变的容易,同时让复杂的事情的实现成为可能
2、Convention Over Configuration --约定高于配置
Rails几乎成了敏捷web框架的代名词,Java社区的Grails,.NET开源项目Mono Rails和Subsonic,还有微软ASP.NET Team正在做的ASP.NET MVC框架无不体现着上述两项设计理念。
看看在.NET进行Rails式的敏捷开发工具包:
1、MVC框架: 无论是Castle MonoRail还是ASP.NET 的MVC框架清晰,简洁,你要用这两个开发web框架,就一定要按他的方式做,model文件就放在models目录里,controller,view,helper分别放在特定名称的目录里,只要你按这个规则做了,那一切很简单,如果你较真抬杠非不这么放,那么也许能达到目标,但很累。不过在他的地盘上开发,为什么要不按人家的规则做呢,况且人家的目录结构,命名规则以及URL到action的映射都很合理很清晰,Mix上会发布的asp.net mvc 在URL Routing上会有很大的增强,MonoRail项目也在加强URL Routing这块的内容,看来自己要创建一套规则也容易。只是自己创建一套规则是否会更好。
2、O/R Mapping: NHibernate,IbatisNet等ORM架构都有至少有一个记录OR映射关系的配置文件,然而Rails框架没有,它使用Scaffold生成model,默认情况下就是英文复数的表名对应单数的Model,DB字段名对应Model字段名,表中必须有叫做ID的×××字段作为key等等很直觉的约定。这样开发者就不用为了“可能”存在的灵活性而维护一个大的OR Mapping配置了。这样简单的事情容易了。SubSonic项目和Castle的ActiveRecord的子项目,由于.net静态语言的原因,在动态特性的实现上没有RoR中那么灵活,它基于.net中的attribute来标识字段和关系,SubSonic 不是在运行时执行基于反射的映射,而是直接生成和编译数据访问层。他们的设计模式都是ActiveRecord,ActiveRecord做CRUD很简单,每个对象可以有自己的Fetch,FetchByxxx方法,从开发者的角度看这些对象,它们知道如何加载和保存自己,对象自己来维护IsDirty之类的标识,开发者不必关心这个对象应该被insert还是update。
3、Ajax,这年头,一个web框架肯定要支持ajax,asp.net mvc框架目前对ajax的支持方面很多人用jQuery做例子的很多。MonoRail之前默认用的是prototype库,MonoRail团队正在支持其他的javascript框架,可参看jQuery 和 MonoRail
4、Loger: 对一个web应用,log是很常用的,Castle 框架和spring.net,MS企业类库都有log,还有一个更通用的Log库,可参看通用日志
5、Mails: 对一个web应用,log是很常用的,Castle框架里面的支持很全面,从邮件模板到Mail发送的封装等
6、作业调度:对一个Web应用,用作业调度去完成一些系统维护和生成报表功能,是不可缺少的,这也有一个通用的项目支持开源的作业调度框架 - Quartz.NET
7、IOC容器:微软也在搞IOC,名叫Unity ,园子里有兄弟介绍了,可参看依赖注入容器Unity Application Block(1):快速入门。只是这还是一个婴儿,还没法和Castle、Spring.NET等开发了好几年的框架相提并论。
4、动态语言:随着DLR的到来,动态语言也来到了.NET,DLR现在发布Alpha 8, SliverLight 2.0的到来,DLR就将就充当一个重要角色,也就是IronPython、IronRuby这样的动态语言正式进入我们的工具箱。

这么多的工具包,就是没有一个完整包装的框架,最完整的框架算是Castle的MonoRail框架,借助Castle的4年来的积累,还在继续前行,微软要推出asp.net mvc而打断了MonoRail项目的开发步伐。SubSonic 本身是一个功能非常强大的应用程序工具集;如与 ASP.NET MVC 配合使用,它将成为非常有用的应用程序框架。总之,贯穿RoR的设计理念,这点对我们用.NET开发是很好的借鉴。
自由、创新、研究、探索……