Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
関数従属性は多重度に先行して認識される - 設計者の発言
「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるＯＲマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次ＴＴＭレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
