「Microsoft .NET RIA Services Overview」について

Silverlight

n-Tierで構成されるRIA業務アプリケーションをターゲットとしたフレームワークです。
【.NET RIA Services】

ものすごくザックリ言うと、ASP.net側とSilverlightアプリ側で共通した型情報、ロジック
を持つことで、簡単に業務アプリケーションをつくれますよというものです。
"ADO.NET Entity DataModel"と"Domain Service Class"というものを使います。
また、XXX.shared.csと、sharedという特別な名前をつけたモノはクライアントにも自動で配置されます。

System.Transactionを使ったトランザクション処理も有効になります。

以前よりも”使えるようになった”という印象です。
属性設定をすることにより、細かい制御ができるようになってますし。
特に個人的なオススメポイントは、

  • Validationロジックが共有できる
  • DomainDataSourceは大量データを考慮したPageSizeとLoadSizeのオプションが指定できる
  • Metaデータにも細かい仕掛けを仕込むことが出来る

こんなところです。

しかしSystem.Transactionをかけるのはいいんですが、それで果たして実用的な処理速度がでるのか？
という疑問があります。
全体的によくできているとは思いますが、処理的に重い部分は自前で実装したほうがいい部分もありそうです。



【2005年に作ったCV.netの資料】

CV.net では、n-Tierと層が細かく別れても本質は、DB、ロジック、UIの3-Tierなので、全て3-Tierというとらえ方をしてます。
上の.NET RIA ServicesでいうTrust boundariesの部分は、認証を含めたサーバクライアント間の通信インターフェースとして実装しています。
DB上の1テーブルに対するQuery,Insert,Delete,Modifyはテーブルの中身がどんなものであっても共通で処理できるようにしています。
論理的なトランザクションをどう実現するかということで、レイヤ間のやりとりがどうなるかという観点
で、サーバ側処理をどうすべきかを考えていました。

１．データレイヤへのｱｸｾｽを伴う一般的なビジネス処理に対するソリューションパターン
=ﾌﾟﾚｾﾞﾝﾃｰｼｮﾝﾚｲﾔとﾋﾞｼﾞﾈｽﾚｲﾔとのやりとり、ﾋﾞｼﾞﾈｽﾚｲﾔとﾃﾞｰﾀﾚｲﾔとのやりとりの２つの入出力に着目し、
　それに適した処理ｺﾝﾎﾟｰﾈﾝﾄを使用する

  • パターンA

プレゼンテーションレイヤ-ビジネスレイヤ間は1sessionで、ｱﾌﾟﾘｹｰｼｮﾝﾃﾞｰﾀの1tableのみを照会、登録、更新、削除する場合

  • パターンB

プレゼン…間は1sessionで、ｱﾌﾟﾘｹｰｼｮﾝﾃﾞｰﾀの複数tableを…..する場合

  • パターンC

プレゼン…間は1sessionで、ｱﾌﾟﾘｹｰｼｮﾝﾃﾞｰﾀの複数tableを…..かつ、1SQL文で処理不能な場合

  • パターンD

プレゼン…間は複数sessionで1transactionを形成、ｱﾌﾟﾘｹｰｼｮﾝﾃﾞｰﾀの複数tableを…..かつ、1SQL文で処理不能な場合

  • パターンE

プレゼンテーションレイヤからみた大量の帳票印刷処理(百P-千P程度)