这两天看了一本书《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开发是很好的借鉴。
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开发是很好的借鉴。
本文转自 张善友 51CTO博客，原文链接：http://blog.51cto.com/shanyou/73874，如需转载请自行联系原作者
