はじめに
前回はRuby/PHP/Perl、それぞれの言語ごとにフレームワークとテンプレートエンジンについて比較を行いました。これにより、現在のWebアプリケーション開発に求められる仕組みを俯瞰できたと思います。
今回はこの比較を基に、Ruby on Railsのこれまでの動向を追いながら、『どのようなフレームワークが自分にふさわしいのか』を考えていくことにします。また、最後に前回の記事で掲載しきれなかった各言語のフレームワークを紹介します。
「Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門」これまでの記事
フレームワークについて調査・分析を
フレームワークの目的は、汎用処理を系統立てた仕組みの中に内包することで、プログラマの作業の効率化とWebアプリケーションの保守性を高めることにあります。Web開発においてはぜひ、導入を検討したいものです。
フレームワークの仕組みついては第1回で概要を紹介しました。では、フレームワーク自体を作成した人は、どのような考えで、フレームワークを設計したのか。ここではその設計思想について触れてみます。
Rubyにおける“Ruby on Rails（RoR）”はここ数年の間に登場したMVCフレームワークのアーキテクチャの雛形となり、Web開発で使用されるさまざまな言語でその思想が反映され、フレームワークが生まれてきています。そのRoRの基本理念として提唱されているキーワードは次の2つで、近年のフレームワークの指標となっていると言ってもいいでしょう。
「同じことを繰り返さない」（DRY:Don't Repeat Yourself）
「設定よりも規約」（CoC:Convention over Configuration）
この連載では度々フレームワークの比較・分析を行う際に、大規模開発向け・中小規模向けという表現をしてきましたが、そもそもこの「規模」とはどの範囲を捕らえたものかというと、サーバーサイドプログラムで実装する機能の開発ボリュームを基準に測定しているものです。
しかし、RIAの隆盛により、ここで使用している小規模という尺度が、Webサービスには当てはまりにくくなっています。
近年のWebサービスでは、サーバサイドでの開発ボリュームは小規模でも、長い開発期間を要するものがあります。というのも、コンシューマ向けサービスでは、画面上のデザインやサイトの構成が頻繁に更新される傾向があり、その実装方法もさまざまに変化しているためです。
また、第1回で示唆したように、クライアントサイドの実装技術にはFlash、SliverLight、Ajaxなどのスクリプトフルな技術が登場してきています。これらは新しい技術であるため、それぞれの技術に特化した作業者・プログラマは、あまり多くないという現状があります。
Webデザイナーやコーダーがこれらの技術を担当することもありますが、サーバーサイドとの連携やスクリプトの量を考えると、実装にはプログラムのスキルが必要とされる可能性が高いでしょう。
今後のWebプログラマの展望を考えた場合、再利用性の高いフレームワーク選定し、サイト構築時の開発負荷を軽減しておくことが重要だといえます。
