 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||
|
||||||||||||||||
| アーキテクチャの比較結果 | ||||||||||||||||
|
ここまで解説してきたことを比較すると、Railsでは「既存システムのテーブル構成の崩れ」や「今後フレームワークが衰退するリスク」といった、現在から未来にまたがる煩わしい問題を気持ちよく切り捨て、記述量を最小限に抑制できる方法を選んでいます。 一方Java陣営では、ある程度の記述量がかかっても、これらの問題に柔軟に対応できる冗長な構成を選んでいます。 世にある開発案件では、ゼロからテーブル設計ができるとは限りません。既存のシステムのDBを利用しながら開発するような状況では、Java陣営型のアーキテクチャの方が向いているでしょう。またフレームワークが衰退していくスパン（5〜10年程度）を超えてメンテナンスをしていくシステムにも、エンジニア確保の観点からJava陣営型のアーキテクチャが適しているといえるでしょう。 逆に新規にテーブル設計から行える案件であり、5〜10年以内に全面リプレイスが予想されるシステムなど、開発効率が第一に求められるような案件ではRails陣営のアーキテクチャを用いた方が適していると考えられます。 |
||||||||||||||||
| マッピング記述の比較 | ||||||||||||||||
|
続いて、オブジェクトとテーブルの対応関係を紐付けるマッピング記述の比較をしていきましょう。 Railsが提唱して以降、Convention over Configuration（CoC）というキーワードが非常に注目されています。CoCは「規約は設定に勝る」と訳され、端的にいうと命名規約によって設定ファイルなどのコードを削減するという考え方です。 マッピング記述の分野にCoCを適用すると大幅なコード削減につながることが知られており、CoCへの対応はもっとも重要であるといっても過言ではありません。 |
||||||||||||||||
| ActiveRecordのマッピング記述 | ||||||||||||||||
|
ActiveRecordはCoCにのっとっており、規約に従うことでコードを削減するスタンスを取っています。ActiveRecordで決められているマッピング記述削減に関する規約（一部）は下記のようなものです。
表2：マッピング記述削減に関する規約（一部） ActiveRecordを用いた場合のソースコードの例を以下に示します。
このように記述するだけでActiveRecordはZooクラスとZOOSテーブルを関連付け、データ操作できるようにし、さらにカラム名と同名のアクセッサメソッドを自動的にZooクラスに追加してくれています。また、has_many宣言（正確にはメソッド）によって関連を持つAnimalオブジェクトを取得するメソッドが動的に追加されます。 |
||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
