Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
