 |
||||||||||||||||
|
||||||||||||||||
| 1 2 3 4 次のページ | ||||||||||||||||
|
||||||||||||||||
| はじめに | ||||||||||||||||
|
本連載では今話題のフレームワーク「Ruby on Rails（以下、Rails）」と現在Webアプリケーション開発で主流であるJavaのフレームワーク群を比較していきます。 比較軸については、開発に関する事項（生産性やメンテナンス性など）を中心に解説していきます。第1回の今回はO/Rマッピングを提供するフレームワークについてです。 |
||||||||||||||||
| 取り上げるO/Rマッピングフレームワーク | ||||||||||||||||
|
O/Rマッピングとは、オブジェクトとRDBのテーブルをマッピングすることをいいます。O/Rマッピングフレームワークはオブジェクト指向とRDBの仲介人となることで、アプリケーションの開発生産性を向上させます。 Railsからは同梱の「ActiveRecord」というO/Rマッピングのコンポーネントを取り上げます。対してJavaのO/Rマッピングとしては、もっとも知名度が高いと考えられる「Hibernate」と、Javaの正式仕様として策定された「Java Persistence API（以下、JPA）」を取り上げます。 また今回はHibernateは2.xを用います。Hibernate3.1以降ではHibernate Annotationsを用いることでJPAに対応でき、比較しづらくなるためです。
表1：今回取り扱う製品 |
||||||||||||||||
| アーキテクチャの比較 | ||||||||||||||||
|
まず各製品を用いた場合のソフトウェアアーキテクチャを比較していきましょう。もちろん各製品とも単なる1つのソフトウェアですので、カスタマイズすれば様々なアーキテクチャに対応が可能です。しかし、ここでは各製品が想定しているアーキテクチャを取り扱っていきます。 |
||||||||||||||||
| ActiveRecordを用いた場合 | ||||||||||||||||
|
ActiveRecordという名称は、2002年にマーチンファウラー氏が著した書籍「Patterns of Enterprise Application Architecture（PofEAA）」で紹介されたActiveRecordパターンに由来しています。
参考文献
Patterns of Enterprise Application Architecture Martin Fowler著、Addison-Wesley Pub刊（2002/11/5） ・日本語翻訳版 エンタープライズアプリケーションアーキテクチャパターン 翔泳社刊（2005/4/21） ActiveRecordパターンは「アプリケーション側のモデル構造とDB側のテーブル構造を1:1対応させる」という割り切った特長を持っています。このActiveRecordパターンはシンプルな考え方であり、クラス数も比較的小さくなるため、ソースコード量を抑えることができるというメリットがあります。 ただし、性能上の理由で非正規化が進んでいた場合や設計ミスなどでテーブル構造が崩れている場合、アプリケーション側のモデルも崩れてしまいます。  図1：ActiveRecordが想定するアーキテクチャ
※注1：
ActiveRecordは「ドメインロジックをモデルに持たせる」という特徴も持っています。ドメインロジックの配置場所については今回は扱いません。
|
||||||||||||||||
| Hibernate／JPAを用いた場合 | ||||||||||||||||
|
HibernateとJPAは類似したアーキテクチャを想定しているため、まとめて取り扱います。両フレームワークは、先述したPofEAAで紹介されている「DataMapperパターン」を実践しています。 DataMapperパターンとは「アプリケーション側のモデル構造とDB側のテーブル構造をn:n対応とし、それらをマッピングさせる」というものです。 また、Javaでは書籍「J2EEパターン（注2）」などで提唱された、DataAccessObject（DAO）クラスを作成することが一般的です。これは可読性やテスタビリティを向上させます。また、特定のフレームワークに依存したロジックを局所化できます。フレームワークが衰退しエンジニアの確保が困難になっても、新たなフレームワークへ乗り換えやすい構造といえるでしょう。
※注2：
J2EEパターン—明暗を分ける設計の戦略
Deepak Alur著、ピアソンエデュケーション刊（2002/07） これらの特徴はいずれも拡張性や既存案件への適用可能性の向上につながっていますが、一方でシンプルなアプリケーションには冗長な記述が発生してしまい、ソースコード量が増加するデメリットがあるのです。  図2：JPA/Hibernateが想定するアーキテクチャ （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||||||
|
1 2 3 4 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
