著作一覧 |
最近の傾向だと思うが、社内にファイアウォールを導入して基幹システムネットワークとオフィスのネットワークを分断しているシステムに出会うことがある。
このようなシステムに既存のソリューションを適合させる事を考えると、WCF Data Serviceは相当良いところをついている。
が、何点か引っ掛かっている。
インターセプト可能なポイントが少ない事と、情報の分散だ。
とりあえず、クェリストリング指定でJSONで返す方法を調べて、属性で介入するコードが提供されていることはわかったから、それを読めば、シリアライズする方法はわかるだろう。
もう一点はキャッシュで、DataServiceクラスの唯一の仮想関数を使った介入を試すと、独自に設定したEtagが悪さをして、リクエストが40xのエラーではじかれる。介入して、リクエストオブジェクトからif-not-matchを削除してやっても、どうも与えられているのはクローンらしく、効かない。
WCFサービスを作ればそのあたりのハンドリングは簡単だろうが、データサービスの雛形生成の強力さが失われてしまう(サービスからデータサービスへリクエストするのは馬鹿げているし、かと言ってコンテキストをインポートするのも無駄だ。とすると、普通にADO.NETを使うことになってしまう)。
さて。
JSONP and URL-controlled format support for ADO.NET Data Services
結局、HTTPモジュール(ASP.NETのフィルタ)を記述するしかないのか。
·こっちの方がきれいだ。jsonpattribute
-
IDispatchMessageInspectorを実装して、フォーム認証のクッキーを確認する、アプリケーションレベルのアクセスログを行き返りで採る。リードオンリーキャッシュを実装するとかすれば良さそうだ。
ジェズイットを見習え |