Rails架構流行在他的設計理念

這兩天看了一本書《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開發是很好的借鑒。

自由、創新、研究、探索……