前から書く書く言って、書いてなかったので。
- 水色：クライアントサイドで処理
- 黄色：サーバサイドで処理（Action部）
- 緑色：サーバサイドで処理（Service部）
Webアプリケーションを構築するときに、
Actionまでまとめて「HTMLクライアント」って考えることで
「リッチクライアント」と同等に並べる事ができるよね、って話。
図から見ても分かるように、
FlexやSilverlight、あとSwingとかUrumaみたいな
いわゆる「リッチクライアント（RIA）」の責務と、
「HTML ＋ Action」の責務は、ほぼ同等でしょう。
それを利用して
HTMLベースのアプリケーションを構築する時に、
いったん「RIAだったらどうするか」を考えてみることで
物事が上手く整理できるんじゃないかな、と。
たとえばセキュリティ。
RIAの場合、どこでセキュリティを保つかって言うと、
Service層の入り口しかない。
クライアントサイドでいくらValidationをした所で
リクエストの改ざんや、重複リクエスト、
あとはCSRFみたいな攻撃も含め、やはり防ぎようがないでしょう。
だから、Serviceの入り口で、
- データの整合性チェック（データに矛盾がないか？）
- データアクセスに対する認証（その権限で、そのデータをCRUDできるか？）
- 二重送信などの誤操作チェック
なんかを行うべき。
特にInsertする時なんかは、
- クライアントからInsert要求を送信
- サーバがいったん受け入れつつも、Insert要求から計算したキーを返す
- クライアントからInsert要求にキーを付加して送信
みたいな処理フローが必要になるはず。
で、これをRIAに限らず、
HTMLベースのWebアプリケーションでも
同じようにやれば良いんじゃないかな、と。
つまり、
Validationで無理にセキュリティを保とうとしない。
リッチクライアントのValidationはあくまで
「ユーザビリティ」のためだと思うけど、
それはHTMLクライアントであっても一緒。
強引な画面遷移とか、hiddenの書き換えとか、クエリ文字列書き換えとか、
やりたければ、好きなだけやらせれば良い。
すべて「Service」側の「Verifier」で防ぐ。
こんな風にやれば、うまく整理できる気がするし、
何より、
RIAとHTMLの両方に対応したWebアプリケーションを
構築しやすくなるんじゃないかなって思う。
