.NET RIA Services 初探與Silverlight 3 資料繫結技術的里程碑

發展RIA 商業應用程式最大的挑戰,不是動畫、不是視訊播放、更不是炫到翻的3D,而是傳統程式的基礎功能,Create, read, update and delete (CRUD),資料的增、查、改、刪等四項基礎功能,是的,你可能很難想像,Silverlight 炫目華麗的表象背後,對這些傳統開發技術能輕易實作的核心資料存取功能,甚至完全沒有標準、實際的作法,可以讓程式開發人員解決相關的問題,是的,沒有。

微軟當然知道CRUD的需求問題,只是Silverlight一開始將所有的挑戰放在發展視覺化介面呈現的能力,實踐RIA必須具備的高度互動能力,也就是我們所熟悉的Flash設計功能,因為這是建立RIA最重要第一步,也是吸引目光的焦點,Silverlight 2之後,相關的基礎功能事實上幾乎已經完備,而接下來,微軟終於也沒有讓我們失望,.NET RIA Services在Silverlight 3被提出來了,這是Silverlight技術相當重要的里程碑,有了相關的服務,我們終於可以輕易的撰寫自訂的商業邏輯,讓Silverlight直接存取後端ASP.NET伺服器進行溝通,存取底層的資料來源或是資料服務,就如同傳統的雙層式架構一般,快速的開發RIA 商業應用程式。

一直到今天,很多程式設計師還是不清楚,ASP.NET其實只能在伺服器端運作,所有在瀏覽器看到的ASP.NET網頁,事實上在它從伺服器送出來之前,就已經建立完成了,換句話說,它是一個死的介面了,因此,完全沒有辦法與使用者作互動。

RIA改變了傳統ASP.NET系統的運作模型,取代網頁來呈現所需的視覺化介面,因此,使用者可以跟RIA應用程式進行互動,但是相對的,另外一個問題產生了,原來ASP.NET網頁與後端資料庫直接溝通的能力沒有辦法延伸至網路的另外一邊,在網路這一邊的Silverlight與後端資料庫的聯繫,便發生了極大的問題,換句話說,CRUD的每一個動作,從最簡單的資料存取,一直到複雜的資料讀寫邏輯運算,都很難被完成。

由於必須跨越網路,因此,RIA必須透過三層式架構,來處理後端資料來源的溝通聯繫作業,三層式架構本身就不容易實作,在ASP.NET,至少,辛苦一點,並沒有太大的問題,但是RIA必須跨越網路,一旦經過網路,事情就沒有這麼簡單了,你可以想像那種複雜度,因此在 Silverlight 3 之前,實作任何與資料處理有關的Silverlight商業應用程式,幾乎是開發人員的惡夢,因為我們必須透過各種不完整、傳統應用程式專用的技術,來湊出所需的Silverlight資料存取功能,當然,沒有什麼事情解決不了,不過,這一層技術的高牆橫在前面,我想,沒有理由,我們 要自己找麻煩去開發 RIA,或許Ajax還是一個比較好的解決方案,至少資料存取的直接問題還是丟給ASP.NET在處理。

.NET RIA Services為了解決上述的問題被發展出來,它對於Silverlight的重要性,幾乎就是ADO.NET之於ASP.NET,儘管這樣形容不盡貼切,但精神是一樣的,談到這裏,我們可能又要開始焦慮了,哇,又是一個新技術,有完沒完?

沒完是真的,可喜的是,有基礎的你並不需要太過擔心,就如同其它的服務,你只要新增此種類型態的服務,如上圖,一種稱為DomainService的類別檔案(實際上就是一個cs類別檔),透過我們已經具備的能力,包含C# 語法與LINQ資料存取技術建立其邏輯內容,就能直接與ASP.NET進行橋接…


換句話說,有了.NET RIA Services,我們就可以將心思放在處理真正所要解決的商業邏輯問題,這也讓Silverlight 3正式成為可以用來發展RIA 商業應用程式的RIA技術。

4 則留言:

kiwi 提到...

聽說有DataSource 和DataPager
看來3.0比2.0更令人期待

康廷數位 提到...

其實,目前看來,進入Silverlight 3.0,Silverlight才正式支援資料存取技術,讓Silverlight能夠開始追得上ASP.NET等成熟的技術了。

可以直接從.NET RIA 服務進入Silverlight 的世界,這是一個好的起點。

匿名 提到...

看了 .Net RIA Services 技術後,其採 DomainContext 的作法,Bussiness Logic 跟 DB 層綁得更死了,原本 OO 與關聯式的世界並非一對一對應的,資料庫中有 Employee 資料表,在商業層中未必就一定有 Employee 這個 Entity! 從 .Net RIA Services 的 Exapmple 中,就以 LinqToSqlDoaminService or LinqToEntitiesDomainServices 直接跟 DAL 層綁在一起,在精神上,似乎違背了 N-Tiers 的原則。這樣的作法正確嗎? 還是我可以在中間再分層呢? 還請呂老師指點一下,謝謝!

康廷數位文教網 提到...

其實應該不會啦,範例總是以最典型的示範
一對一是最好講解的,所以以此種方式來作說明是最清楚的…

.NET RIA 我也是算入門階段,得要到正式版出來,我才會更進一步探究它的內容,目前無法給你太多的建議…

不過即然是N-Tiers,如果作到挷死就不用玩啦,呵,Entity本身是透過類別將資料庫的二維結構壓縮成為集合類型的一維的資料結構來玩,即然是類別,當然就可以讓你彈性的亂寫呀,所以這一點幾本上是不用擔心的XD…

至於細節,建議可以參加MS舉辦的「Silverlight 3 技術講座」,其中針對NET RIA Services 這一部份,奚江華老師應該會有超精辟的解析…

Silverlight 3 技術講座 網址:

http://msdn.microsoft.com/zh-tw/dd996595.aspx