 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||
|
||||||||||||||||
| その他の比較 | ||||||||||||||||
|
第6回から通じて、アーキテクチャ、ジェネレータ、コントローラ、ビュー、モデルについて比較してきましたが、コネクションプーリングと実行環境の違いについても検討します。 |
||||||||||||||||
| コネクションプーリング | ||||||||||||||||
|
Railsでは1プロセスあたり1つのデータベースコネクションを保持するようになっており、コネクションプールという機構自体は持っていません。 GrailsではJavaEEで規定されたコネクションプール機構を用いてプーリングが実現されるため、プールするコネクション数の上限などがチューニングしやすいといえます。デフォルトのコネクションプールには、オープンソースで実装されたDBCPが用いられます。必要に応じて、アプリケーションサーバが提供する実装に切り替えることも可能です。 |
||||||||||||||||
| 実行環境 | ||||||||||||||||
|
Railsが採用してる言語Rubyは現在のところインタプリタとして動作し、速度向上には限界があるとされています。 Ruby 2.0ではYARV（Yet Another Ruby VM）という独自のRubyVMが導入されるといわれており、実現されれば速度が向上する可能性があります。 Grailsが採用している言語であるGroovyはJavaVM上で動作します。 既に枯れた技術に入りつつあるJavaVMは、高速でかつ安定していることが知られています。現在のところGroovyはJavaほどの速度を実現できておらず、今後のチューンナップが期待されます。 両者ともVM上で動く方向に進んでいますが、Rails陣営はまだVMの正式リリースがされていない状態である一方、Grails陣営は既にVM上でのチューニングが進められるステップです。この点ではGrailsの方が進んでいるといえるのではないでしょうか。 |
||||||||||||||||
| 比較のまとめ | ||||||||||||||||
|
以上、RailsとGrailsの比較を進めてきました。 まとめると、GrailsはRailsを比較的忠実にコピーしており、有用な特性が十分に移植されてきているといえます。 また、サービスクラスを導入して堅牢なアーキテクチャを目指していたり、トランザクションが自動で全サービスメソッドに掛かったりするなど、Railsにはない更なる改善を目指している様子も見て取れます。 加えてJavaという性能面や安定性で多くの実績を持ち、またライブラリやデベロッパの多い実行環境上で動作することを考慮すると、Railsの対抗馬として考えられます。 ただし、スキーマ情報の管理方法に性能上の明らかなデメリットが存在するなど、まだまだ改善の余地はありそうです。 |
||||||||||||||||
| おわりに | ||||||||||||||||
|
第1回からRailsとJavaの比較を進めてきました。いかがでしたでしょうか。 連載全体を振り返ると、やはり拡張性のJava、生産性のRailsということになると思います。これは、どちらが優れているというわけではなく、案件の性質に応じて適切に使い分けることが重要だと思います。 また、Grailsについては今のところさほど知名度はありませんが、プロダクト自体はしっかりしたものです。今後の動向によってはJavaやRailsのマーケットに食い込んでいく可能性もあると思います。 Railsの実績は確実に増えて行っています。GrailsのようにRailsに影響された有力なプロダクトも続々と出現してきています。 今後も確実に動きをキャッチアップし、Rails界隈の動向を早期に見極めることが重要であるといえるのではないでしょうか。 |
||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
