O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」

昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ

[yatata]

“Ruby on Railsの『えせMVC』の弊害”

[knmsyk]

この業界でプロとして仕事をするなら、使う言語やフレームワークにかかわらず、オブジェクト指向とMVCのコンセプトだけはしっかりと理解した上で仕事をしてほしい。

[holypp]

O/RマッピングからMVCのあるべき形を。また、Rails上で犯しやすい設計上のミス

[skatsuyama]

設計について、Model != ActiveRecord だよと言っている記事。

[bigbro]

これも釣り

[cooldaemon]

いま、perl 界隈でも同じ事が起きている。Martin Fowler の本を何冊か読んで欲しい。

[nelnal_programing]

開発者がしっかりとデザインパターンを理解していないことで間違ったフレームワークの使い方をしてしまって、それによって難解なソフトが出来るという話か？

[k-takahashi]

『Modelの中に記述すべきビジネスロジック（ビジネスルールに基づいてデータベースにアクセスし、データの整合性に責任を持つロジック）を Controllerの中に記述しはじめ』『Controller層が必要以上に分厚く』

[banana-umai]

[O/Rマッピング]

[hamasta]

業界団体が標準技能として定義すればいいのに

[tnk962]

結局DB設計だ、とか、DOAだ、とか、Railsについて言ってた人がいたことを思い出した。

[Chisei]

『MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている』もっと勉強しようと思った。

[koumiya]

最近経験したプロジェクトはテーブル設計≒ドメイン設計になっていたので恩恵は十分に受けていたな。つか、何処に書けばいいか分からないからとりあえずコントローラへなPGが多いのが問題って話か。

[mujin]

よく分からんのだけど、コントローラがO/Rマップされたオブジェクトにアクセスするのをエラーを吐くとかでフレームワーク側で禁止できないの？禁止しない理由はないような気がする。

[thesecret3]

スパゲッティかどうかはアーキテクチャの問題ではないことが多いかと。むしろ同じスパゲッティなら一ヵ所にズドンと書いてあるほうがいいかも。。

[raitu]

//本来ならModelの中に記述すべきビジネスロジック（ビジネスルールに基づいてデータベースにアクセスし、データの整合性に責任を持つロジック）を Controllerの中に記述しはじめてしまい、結果的にController層が必要以上に

[kazutanaka]

負のスパイラル

[xucker]

実体験のRailsはさておき、JavaにまでFUDするのは止めて欲しい

[willnet]

Modelをなるべく分厚くしていきたいとは思っていても、どうしてもControllerに書いてしまうことが多いなあ(特に複数のModelにまたがる処理)／そこらへんうまくやれるコツみたいな情報ないかな

[y-kawaz]

本来ならMVCのMは、ビジネスルールも理解して整合性を保ってくれるDAOであるべきだが、その裏にあるただのツールであるORマッパーがMであると勘違いして直接触る人が多くて困る、という話か。

[kzfm]

本来ならModelの中に記述すべきビジネスロジック（ビジネスルールに基づいてデータベースにアクセスし、データの整合性に責任を持つロジック）を Controllerの中に記述しはじめてしまい、結果的にController層が必要以上に分

[yojik]

ドメインモデル貧血症とエセMVC?は関係が無いわけじゃないけど混同すると議論が迷走するのでよくない。 あと日本語訳も紹介していいと思います。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

[kodaif]

"使う言語やフレームワークにかかわらず、オブジェクト指向とMVCのコンセプトだけはしっかりと理解した上で仕事をしてほしい。そして、O/Rマッピングを使う時には、それだけでModel作りが終わったと誤解してはいけない"

[rockyosaka]

RailsのFUD（若干「釣り」らしい…）→論点ずらし＆開き直り。正直ちょっと見苦しい。

[da-yoshi]

Rails自身はこういう議論が一周した後に、現実的に作りやすい形ということで今の形態になっていると思うんだけどな。ビジネス層とか考えすぎて複雑怪奇になったシステムというのも現実にはあるわけで

[yssk22]

これはすばらしい。ということでみんなドキュメント指向するといいよ！ | でも Application Architecture of .NET はその辺よく書かれていたと思うんだが。読まれないってことかorz