BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Service Oriented UI(SOUI)の出現はMVCの死を意味するのだろうか?

Service Oriented UI(SOUI)の出現はMVCの死を意味するのだろうか?

Model-View-Controllerパターンは XeroxPARCでGraphical User Interfacesが発明されて以来、アプリケーションアーキテクチャの必需品となった。そのパターン自体はTrygve Reenskaug氏によって発明された(英語・PDF)。そしてそのパターンはWebアプリケーション(source)(このアプリケーションはJava WorldにおいてはMVC2(英語・PDF)として知られている。)をサポートするために90年代中盤に適合された。

この適合されたパターンはコントローラからビューを更新する能力に欠けていたので、通常ユーザはその更新されたコンテンツを見るためにページをリフレッシュしなければいけなかった。その理由にはサーバからクライアントへのコネクションがあったからである。Ajaxian Frameworkの到来と共に、このコネクションは今や模倣されつつある。2006年で一番人気だったAjaxフレームワーク(source)のPrototypeは MVCなしで(source)開発され、また遠隔フレームワークとよりシンプルなDOM操作を提供した。このケースにおいてデベロッパはMVC2を含むMVCパターンの実装する方法を選択することができる。他のJSF/Ajax4JSF(source)とRuby on Rails(source)のようなフレームワークはMVCがどのように実装されているかという観点において、遥かに規範的なのである。

Nolan Wright氏はMVC実装は時代遅れであると考えている(source)

MCVベースのフレームワークは単にデザインによってAjaxとDHTMLの力をフルに活用することができず、(しかしながら)これらの(たくさんのフレームワーク)はAjaxのサポート(例:JSF/Ajax4JSF(source)とRuby on Rails(source)を通したJBoss Seam)を付け加えた。Ajaxはユーザインターフェースとサーバ間で100%に近い疎結合を可能にする一方、それらはユーザインターフェースとサーバ間での密結合を強要する。

それゆえに、私たちは一歩戻って新たな見通しを持ってWeb開発の問題に目を向けなければならないのだ。

Jeff Haynie氏は下記のように同意している(source)

リファクタリングで私たちは改善することが可能になり、またそれによって頻繁に向上が成されるのです。しかしながらたまに一歩戻ってみると、デザインの毛玉に直面するときがあります。それが私たちが今日Webアーキテクチャにおいて抱えている問題で、またそれは私がなぜRuby on Railsのような軽量のフレームワークが幅広く成功してきたかという理由でもあるのです。

今日JavaにおいてシンプルなWebアプリケーションを試みてみましょう。フレームワークに名前を付けますか?本当にやっかいですね。気が遠くなります。XML設定ファイル、Webフロー、JSP、コントローラー、モデルとDAO、WARファイル、JARなどなどたくさんあります。そして今度はあなたのレイアウトをリファクタしたいのですか?もう止めたほうがいいでしょう。

もうたくさんなのです。私たちはRich Internet Applicationを構築する方法としてのサーバ側のMVCを真剣に再考する必要があるのです。

NolanとJeffはSOAがソリューションの一部であると考えている。

実際にサービス指向のアーキテクチャ(SOA)を作る機会を設けましょう。SOAは単なるWebサービスの付属物ではありません。そしてそれは後知恵の産物でもなくミドルウェアの積み重なりの中のガラクタでもないのです。そうです、それはデザインの中枢であり、それが主となるものなのです。

Nolan氏はServices、AjaxとDHTMLに基づいた新たな基盤SOUI(サービス指向のユーザインターフェース)を提供している。

AjaxとDHTMLは非常に補足的なテクノロジーで、統合されると今日のデスクトップアプリケーションの能力を上回るWebアプリケーションの構築を可能にします。結果として次世代のWeb SDKが必要とされるのです。それもシームレスにAjaxとDHTMLを統合するものです。

次にNolan氏はブラウザ内でコントローラをデプロイするのは全く問題ないことを説明している。

一つのメッセージで3つのHTML要素を隠し、もう一つを表示し、サービスリクエストを送ることができるのです。かなり使えますね。

Nolan氏が挙げた利点は下記のとおりである。

  • SOUIは軽量のメッセージを使用してサービスに話し掛けるので、サービスは今ではどのプログラミング言語でも記述されることができるのです。言い換えると、SOUIはプログラミング言語を問わないのです。SOUIコード一つ変更する必要なしに、サーバープログラミング言語を変更することができるのです。
  • SOUIとそのサービス間でシンプルなメッセージに基づいたコントラクトを生成することができます。結果は完成に近いクライアントとサーバの疎結合なのです。それらは軽量のメッセージコントラクトのみによって結合されているのです。
  • ローカルモックメッセージハンドラーを使用することができるので、それらは完全に機能するクライアントのみのプロトタイプを生成することができます。SOUIはモックメッセージハンドラーとサービスの使用の違いを認識しないのです(準備ができたらメッセージハンドラーをリアルサービスに変更するだけです。)。

Jeff氏は下記のように結論を下している。

シンプルに戻りましょう。何が本当に大切か考えてみましょう。アプリケーションをつくることですね。複雑なサーバアーキテクチャはもう十分なのです。

原文はこちらです:http://www.infoq.com/news/2007/11/soui-death-of-mvc2

この記事に星をつける

おすすめ度
スタイル

BT