トップスポーツチームの監督に教わる秘訣
この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
作者 Jean-Jacques Dubray, 翻訳者 編集部 投稿日 2007年11月12日 午後6時6分
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氏は下記のように結論を下している。
シンプルに戻りましょう。何が本当に大切か考えてみましょう。アプリケーションをつくることですね。複雑なサーバアーキテクチャはもう十分なのです。
セキュアなIT基盤と付帯運用サービス”SecureOnline”
12/16 ~野村総合研究所が提案~ 「不況を乗り切る!効果的なIT投資を考えるセミナー」
【無償】「Google Apps 企業向けソリューションセミナー」のご案内
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。
筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。
エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。
この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。
No comments
返信