O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
あなたがRoRを使わない10の理由に違和感を感じる幾多の理由 - moriyoshiの日記
別に個人的にGREEでEthnaを使ってたから、とか藤本さんと個人的に知り合いだからだとかそういう理由じゃなくても、ここでEthnaが引合いに出されるのはやっぱり違和感がある。だからあえて書く。勘違い君を増やしたくないので、ネタにマジレス。 EthnaってあのクソなStrutsの劣化コピーwwwwww -- Ethnaは確かに洗練されたフレームワークではない。それは誰しもそう思うだろう。実際に一緒に仕事をしていた同僚はみなRoRを引合いに出しては「なんでEthnaには○○がないの?」と言っていたように思う。でも、フレームワークって洗練されているか否かという観点で語るもんじゃない。現実世界の問題 (つまり案件一つ一つ) を、どうやって大勢でよってたかって解決するか、という解法に対するアプローチに過ぎないからだ。そして、いかなるアプローチでも現場の大多数が違和感を感じるならそれを選択するべきで
[ThinkIT] 第1回：O/Rマッピング (1/4)
本連載では今話題のフレームワーク「Ruby on Rails（以下、Rails）」と現在Webアプリケーション開発で主流であるJavaのフレームワーク群を比較していきます。 比較軸については、開発に関する事項（生産性やメンテナンス性など）を中心に解説していきます。第1回の今回はO/Rマッピングを提供するフレームワークについてです。 O/Rマッピングとは、オブジェクトとRDBのテーブルをマッピングすることをいいます。O/Rマッピングフレームワークはオブジェクト指向とRDBの仲介人となることで、アプリケーションの開発生産性を向上させます。 Railsからは同梱の「ActiveRecord」というO/Rマッピングのコンポーネントを取り上げます。対してJavaのO/Rマッピングとしては、もっとも知名度が高いと考えられる「Hibernate」と、Javaの正式仕様として策定された「Java Pers
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
