更新情報

みなさん、こんにちは。唐突ですが、皆さんがRuby on Railsのことを知ったのはいつ頃のことでしょうか。このコラムを今初めて見て知りました!という方はさすがにいないと思いますが笑、最近Railsを知った、興味を持ったという方もいらっしゃるかもしれません。

Railsも気づけば世に出てから10年以上が経過しています。バージョン1.xのころにRailsを知った筆者は、当時オープンソースでMVCのWebアプリケーションフレームワークというと、Strutsしか知らなかったので、Railsの様々な機能や思想に驚かされたものです。

RailsはRubyのためのWebアプリケーションフレームワークですが、Railsのもたらしたものは、その後の様々な他言語の同種のフレームワークに大きな影響を与えています。例えば、PHPの著名なフレームワークでCakePHPがありますが、CakePHPは「Railsインスパイアフレームワーク」とも呼ばれるほど、Railsの考え方を取り入れたフレームワークです。筆者は研修講師でもあるので、Railsの研修講師もするのですが、いつぞや、ある受講者の方がCakePHPの経験者で、ひととおりRails研修を受講された後で「本当にCakePHPはRailsにそっくりなんだと実感できました」という感想を漏らしていたことがありました。

それ以外のフレームワークでも「Railsインスパイア」ではなくとも、その考え方や機能を部分的に取り入れているものが多くあります。JavaScriptのMVWフレームワーク(なぜMVCでないのかは、「MVW」というワードを調べてみてください)であるAngularJS(バージョンアップした現在は「Angular」)には、Yeomanという開発支援ツールがあるのですが、このツールの使い勝手はRailsそのもので、すでにRailsを知っていた私にとっては大変親しみやすいものでした。

そんなわけで、最近私が良く思っているのは「MVCのWebアプリケーションフレームワークを勉強するなら、まずRailsから始めるのがおすすめ」ということです。Railsを学んでおくと、もしその他のフレームワークを使うことがあっても、「お、これはRailsのあのコンポーネントと似ている」とか「あ、これはRailsのあのツールと同じ役割だな」と理解も早まるのではないかと思います。

というのも、私事ではありますが昨年暮れから今年の春まで、JavaのMVC WebアプリケーションフレームワークのひとつであるSpringMVCの研修教材を作成したのですが、SpringMVCを調査して得た感触は「これは、弊社が持っているRailsの教材をベースにして作れば、比較的短時間で教材が出来そうだ」というものでした。そして事実、かなりの短時間で教材を作ることができました。

本当なの?と思われる方もいらっしゃると思いますので、いくつか簡単なコードで両者を比較してみましょう。

例えば、Railsのコントローラクラスは、以下のような感じです。コントローラの基本機能を備えた基底クラスを継承し、リクエストに応じた処理をコントローラ内のメソッドで実行します。

class SampleController < ApplicationController
def foobar
@hello = “こんにちは。Ruby on Rails!”
end
end

対して、SpringMVCのコントローラクラスは、以下のような感じです。SpringMVCでは特定の基底クラスは継承しませんが、アノテーション(@Controllerアノテーション)によってコントローラの機能を注入しています。リクエストに応じた処理は、コントローラ内のメソッドで実行します。メソッドに付与されている@RequestMappingアノテーションは、Railsでいうところのroutes.rbのようなルーティングを指定するものです。
※以下のコードはパッケージ指定とimport文は省略しています。

@Controller
public class FirstController {
@RequestMapping(“/”)
public String index( Model model ) {
model.addAttribute(“hello”, “こんにちは。SpringMVC!”);
return “hello”;
}
}

どうでしょうか。つくりはよく似ているような気がしませんか?

そしてモデルクラスです。Railsのモデルクラスは、対応するデータベースのテーブル定義をもとに、必要な属性やメソッドを動的に追加するようになっているため、簡単な利用だけであればモデルクラスの構造はとてもシンプルです。

class Employee < ActiveRecord::Base
end

対して、SpringMVCのモデルクラス(SpringMVCではエンティティクラスと呼ぶことが多いようです)の様子は以下のような感じです。

@Entity
@Table(name=”employee”)
public class Employee implements Serializable {
@Id
@Column(name=”no”)
private Integer no;
@Column(name=”name”)
private String name;
@Column(name=”salary”)
private Integer salary;

public Employee() {
}

public Employee(Integer no,String name,Integer salary) {
this.no = no;
this.name = name;
this.salary = salary;
}
// 以下、上記フィールドに対するgetter/setterを定義する
}

やはり、コントローラと同じく、@Entityアノテーションでエンティティクラスとしての機能を持たせていますが、コード量がRailsとは全然違いますね。なあんだ、SpringMVCは面倒じゃないか、と思ったかもしれません。しかし、SpringMVCには、これまたRailsの考え方と似たていると思える機能があります。SpringMVCは、サーバの起動時に、エンティティクラスの定義に合わせたテーブルを自動生成する機能があるのです(もちろん、設定で無効にすることもできます)。これは、Railsにおけるマイグレーションスクリプトによく似ていると思いませんか。

Railsでは、マイグレーションスクリプトでテーブルを生成し、そのテーブル定義を参照することによって、モデルクラスの記述からテーブルに依存する内容の記述を減らすことができました。一方、SpringMVCではエンティティクラスでテーブルに含めたいカラムの情報を定義することで、テーブル生成用のスクリプトを記述する必要がなくなりました。そうです、これはまさにDRY(Don’t Repeat Yourself:繰り返しを避けよ)の考え方ですよね。

いかがでしょうか。Railsを知って、その目線で見ると、他のフレームワークもちょっと面白く見えてきて、楽しくなってくるかもしれませんよ。もちろん、Railsを学んで、そのままRailsで開発するのが、一番楽しい