Ajaxアプリケーション開発における7つの大罪

文:Scott Robinson(TechRepublic) 翻訳校正:村上雅章・野崎裕子
2008-01-09 08:00:00
  • このエントリーをはてなブックマークに追加

 実際のところ、こういったことの大半は常識レベルの問題である。本当の問題はこれほど判りやすくはない。

Ajaxの7つの大罪

  1. メモリリークを放置する--開発経験の長い人なら誰でも循環参照について知っており、それがメモリ管理に及ぼす悪影響についても理解していることだろう。Ajaxの中核技術であるJavaScriptは、メモリ管理機能を持ったプログラミング言語である。つまり、JavaScript自体にガーベッジコレクタが組み込まれているため、どこからも参照されなくなった変数は自動的に検出され、その変数に割り当てられていたメモリが解放されるのだ。これは一般的な原則としては正しい。しかし、モデル層のオブジェクトがビュー層の要素を参照しており、そのビュー層の要素が元のモデル層のオブジェクトを参照しているような循環参照が存在する場合、ガーベッジコレクタのこういった働きがあっても、適切なメモリ管理は期待できないのである。モデル層のオブジェクトをNull化することで、理論的にはそのオブジェクトが参照しているビュー層の要素もNullになるものの、ビュー層の要素からモデル層のオブジェクトへの逆参照があった場合、ガーベッジコレクタはそのオブジェクトに手を付けられないのだ。
    ここで、はまってしまいがちな落とし穴に目を向けてみよう。Document Object Model(DOM)において、ドキュメント階層を構成するすべてのDOMノードは、明示的に他のオブジェクトから参照されているかどうかに関係なく、ドキュメント階層中に存在しているという理由だけで参照される可能性があるのだ。このため、DOMノードから逆参照されているオブジェクトをガーベッジコレクションの対象としたい場合には必ず、逆参照を断ち切るためのNull化を明示的に行わなければならない。そうしなければ、そのメモリは割り当てられたままになってしまうのだ!

  2. 「非同期」の真の意味を知らない--非同期というものは、それに慣れていないユーザーを大きく困惑させる可能性がある。しかし皮肉とも言える話だが、あなたが設計し、構築するWebアプリケーションを、デスクトップアプリケーションであるとユーザーが「思えるならば」、非同期に慣れていないユーザーでもそのアプリケーションに困惑を覚えることはないのである。これこそが設計上の重要なツボなのだ!機能的に見た場合、ほとんどのWebアプリケーションはデスクトップアプリケーションとよく似たものとなっている。しかし、Webアプリケーションを「ユーザの期待」という観点から見た場合、際だった特徴が浮かび上がってくるのだ。
    ユーザーがウェブブラウザとやり取りを行う場合、デスクトップアプリケーションを用いる場合とは異なった先入観や期待を抱くことになる。このため、サーバとのさまざまなやり取りをページ上に反映させることで、驚くほどクール、かつ効率の高いページを作成することができるかもしれないものの、ページ自体を頻繁に更新することで、ユーザは絶え間のない変更の集中砲火にさらされることになり、大きな混乱に陥いれられる可能性があるのだ。従って、ユーザから見える「すべての変更」について、2つの規則に従って熟考する必要がある。つまり、その変更がユーザにとってすぐに必要となるようなものでないのならば、ユーザの気を散らさないよう控えめに行われるようにするのだ。そして、その変更がユーザとアプリケーションとの間のやり取りにおいて重要なものであるならば、ページ上に明確かつ目立つように表示するのだ。

  3. サーバを蚊帳の外に置いておく--クライアントとサーバを分離することで、事前にはまず判らない大きな欠点が生み出される。サーバサイドアプリケーションはすべてを掌握しており、すべてのものに目を光らせている。つまり、すべての例外、すべてのリロード、すべてのイベントを監視し、記録することができる。また、基本的にはサーバ自体が画面描画を行うため、端末の画面がどのように表示されるかももちろん正確に判っている。
    しかし、Ajaxアプリケーションの場合は、そのようにはならない。さまざまな処理がクライアント側に任されているため、サーバ側ですぐに把握できないような問題がクライアント側で発生する可能性もあるのだ。そのため、サーバ側でできるだけ早急に問題に対処できるよう、クライアント側でイベントや例外を捕捉し、サーバからアクセスできる場所、形式でログに出力しておくようにしよう。

  4. GETリクエストを使って手を抜く--GETリクエストはデータの取得に、POSTリクエストはデータの設定に用いるためのものである。GETリクエストを、使用するべきでない状況において使用することは、何も問題を起こさないと判っている場合でも避けるべきである。GETリクエストによる状態の変更や、状態の変更を行うリンクはユーザーに混乱を与えてしまう。ほとんどのユーザーはリンクというものを機能ではなく、ナビゲーションの指針として捉えているのだ。

  5. データ型に無頓着である--JavaScriptは.NET Frameworkの一部ではない。これはつらい事実であるかもしれない。しかしこのことで、いつかは直面することになる問題の一端が見えてくるはずだ。そこで、JavaScriptのデータ型と、プラットフォーム(それが.NETであるかどうかに関係なく)のデータ型との間で互換性を確保しておく必要があるということになるわけだ。データ変換に利用できるコンバータにはさまざまなものがあるため、いろいろと探してみるのがよいだろう。例えば、Ajax.NET Proライブラリは.NETとJavaScript Object Notation(JSON)との間のオブジェクト変換を可能にするコンバータを提供している。

  6. 果てしなく続くアプリケーション--動的に生成されるコンテンツに対して何の上限も設けられていない場合、ページがリロードされるかどうかにかかわらず、悲惨な結果となる可能性がある。あなたも、連邦議会の議事録よりも長いウェブページを見たことがあるはずだ。永遠に続くと思えるほど長く、嫌になるほどややこしいウェブページがあった場合、いつまでも続く「アプリケーション」についてユーザーがどう感じるのかを想像してみてほしい。Webアプリケーションのページを動的なものにする場合であっても、何らかの現実的な上限は設けておくべきだろう。

  7. DOMとJavaScriptを分離する--AjaxはModel-View-Controller(MVC)アーキテクチャに従って構築されているということを忘れてはならない。このことを真剣に捉えてほしい。JavaScriptはModel層に位置付けられ、DOMはView層に位置付けられ、Controllerが両者の間の相談役として位置付けられるのだ。こういった位置付けに基づき、Webドキュメントのコンテンツは、JavaScriptが使用されるか否かにかかわらず、同じ内容になるようにしておくべきである(こうしておくことでJavaScriptを使えないユーザを救うこともできる)。ただし、そのコンテンツがJavaScriptを使用できるユーザーにしか意味を持たない、あるいは実用的とならない場合はこの限りでない。つまり、JavaScriptの使用が前提となる場合には、JavaScriptでコンテンツを作成してもよいということになる。

この記事は海外CNET Networks発のニュースをシーネットネットワークスジャパン編集部が日本向けに編集したものです。海外CNET Networksの記事へ

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]