URL

「Life is beautiful: Ruby on Railsの「えせMVC」の弊害」のグラフ

Life is beautiful: Ruby on Railsの「えせMVC」の弊害http://satoshi.blogs.com/life/2009/10/rails_mvc.html
月のグラフ

コメント

(2018/09/23 11:12:35 更新)
  • 今の所MVCのベスト解説 「MVCは、モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するのを避けようという発想」「Model=ビジネスロジックを持ち、データの整合性に絶対の責任を持つ」/Yugui氏コメが最高:vabo-space2016-01-22 04:23:35
  • “素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装”:mtrock2015-08-26 15:06:40
  • Ruby on RailsのMVCについての考察。M = ActiveRecordsじゃないよと意識して使おう。:hidehara2013-12-10 13:00:16
  • Life is beautiful: Ruby on Railsの「えせMVC」の弊害:d_animal1412013-11-16 15:29:55
  • ActiveRecordをModelと言い張る実装のRailsアプリを見てMVC厨が憤慨するいつものパターン。日本語でも2009年からあった。yuguiさんのコメントがすばらしい。:ledsun2013-11-11 11:28:27
  • mvc:toenobu2013-10-21 22:42:06
  • 「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておく:takanamito2013-06-04 14:37:38
  • うーん。コメント欄含めて、か。:cha-cha-ki2013-04-09 13:58:13
  • みんなに読んでほしい:mtmt101jp2013-02-20 18:01:36
  • MVCのお勉強。:senahate2013-02-12 22:45:26
  • わしもブックマークしてなかった。:Nyoho2013-01-06 16:56:24
  • ブックマークしてなかった:muamqm2012-12-25 22:58:31
  • "ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックがControllerに浸食していくことを意識して避けることが大切である。":zbih2012-12-06 16:16:15
  • よく読まれているMVCに関するエントリ。RORのActiveRecordにもう一枚ラッピングしてようやく本来のModelになる。ビジネスロジックの整合性だけは何があっても守りぬいてこそのModel。つまりControllerを薄くせよという話でもあり:zuborawka2012-11-17 15:04:26
  • コメント含めて面白かった:matsumoto_r2012-10-24 14:44:24
  • 『素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックのControllerへの浸食を意識して避ける』:masutaka262012-10-01 02:53:32
  • 久しぶりにYuguiさんの最強コメント見て認識合わせした。:kazuph19862012-07-07 21:34:06
  • 古い記事だけどメモ:zakinco2012-06-11 22:48:51
  • "ActiveRecordは、データベースのテーブルを単にオブジェクトの形に抽象化しただけのものであり、そこにはビジネスロジックは一切含まれていない"というのは不適切すぎる言い方では……:todesking2012-05-11 13:37:39
  • コメント欄が、、、おもろい:takeboruta2012-05-11 13:25:00
  • Railsに限った話ではないですね。わかりやすい説明。:nullpobug2012-03-09 12:04:10
  • Life is beautiful: Ruby on Railsの「えせMVC」の弊害:longroof2012-01-30 18:20:54
  • [Ruby on Rails]:safu08262011-10-22 16:33:29
  • Railsの本読んでて, Modelがやけに薄いなと思ったのは間違いではなかった:y_uuki2011-09-18 23:45:18
  • DataMapperとActiveRecordの違いがだんだん分からなくなってきてモヤモヤ。:escape_artist2011-08-02 17:33:57
  • 後ほどよむ。 Life is beautiful: Ruby on Railsの「えせMVC」の弊害:shiwork2011-06-06 16:14:16
  • ビジネスロジックがControllerに浸食していくことを意識して避ける:northlight2011-05-29 10:30:49
  • ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックがControllerに浸食していくことを意識して避けることが大切:delhicurry2011-05-28 14:50:29
  • 「ビジネスロジックがControllerに浸食していくことを意識して避けることが大切」:suginoy2011-04-04 21:45:40
  • "MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するのを避けよう」というオブジェクト指向の発想がある":may_2chan2011-02-04 13:58:30
  • MVCの考えかた。特にModelについて:malibu-bulldog2010-12-20 13:40:13
  • 「手持ちの現金の増減を記録したテーブル」へのControllerによる直接のアクセスは絶対禁物出来る事rhくらで売ったか」をModelに報告するだけで、その情報に基づいてデータベースに適切な変更を加えるのはModelの役割である:areyoukicking22010-12-05 18:21:39
  • MVC:t_a_o2010-11-22 22:55:50
  • MVCのわかりやすい大事な解説:nishiking2010-11-19 01:47:25
  • Modelをちゃんと捉えよう:toshi32212010-11-11 22:54:50
  • MVCのことをきかれてrorを勉強しようとしてこれを見たらやはりやればいいというものでもない気がしてきた。:unreallight2010-10-19 16:33:15
  • あとでよむ~MVCモデルちゃんと見ておく。:yuchi2010-10-12 19:17:42
  • ARが即ちModelとか、そんな杜撰な設計しているRailsアプリって結構あるわけ?自分は見た事無い。:kimunny2010-06-18 21:11:54
  •  先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View C...:jonysand2010-04-06 04:22:34
  • えぇっと、要するにRubyOnRailsの使い方を間違えてる人が多いよってことでおk?:diveintounlimit2009-11-14 10:47:06
  • O/Rマッパとモデルを同一視する危惧、O/Rマッパとコントローラのあいだのレイヤーのモジュールとしてモデルがあるべきというはなし?:youhey2009-11-12 23:12:14
  • 釣り:bigbro2009-11-03 18:18:26
  • MVC:miyaga2009-10-25 17:34:53
  • コントローラーにロジック書くなって話しだよね。Railsがどうこうという問題ではない気がする。:hokaccha2009-10-24 14:50:19
  • モジュラリティと再利用性の問題であってMVCは関係ないと思うが。/MVCではCの役割が曖昧なので決壊し易いって話かな。:z0rac2009-10-19 16:11:14
  • 5年前に少し齧ったけど、わかったようなわからないような印象しかなかった。今はどうだろう・・・:Zephid2009-10-19 14:35:22
  • まともなプログラマーなら何使っても勝手に MVC な設計になっていそうな気もするがそれはさておき、フレームワークが MVC を指向するならコミュニティは正しく啓蒙していこうよという気概には一理あると思う。:t-murachi2009-10-19 12:46:39
  • 「Modelの外部インターフェイスの設計においてもっとも大切なことは、この「データの整合性」の責任を100%Model側で引き受け、「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておくことであ:rabbit2go2009-10-19 10:19:12
  • 複数モデルを呼び出す順番もロジックなので、厳密にするとコントローラーに記述すべきじゃない、となる。どこまでやるかはケースバイケース。サービス層を知らない人のために http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?ServiceLayer:hiro3602009-10-15 19:40:55
  • つwebobjects:deep-sound2009-10-15 12:32:35
  • いい話。:kabakiyo2009-10-14 18:21:08
  • いまさらながら:bk2462009-10-14 12:35:30
  • PAC ( Presentation Abstract Controller ):oooooooo2009-10-14 11:32:34
  • エントリーもすばらしいが、コメント欄のやりとりがまたすばらしい:noopable2009-10-14 10:52:20
  • コード!!コード!!:bobbyjam992009-10-14 09:21:38
  • mvc:greennoah2009-10-14 00:37:01
  • 普通はなんと呼び分けるのか知らないけど、ドメインモデルとその内部で使うデータモデルがあったとして、本来MVCのMはドメインモデルを指すものなのにRailsのモデルはデータモデルなのでそれで誤解する人が出るよねと。:tsimo2009-10-13 17:17:12
  • もっとも丁寧に設計し徹底的にテストをしなければならないのがアプリケーションの土台となるModel / Modelにバグがあるとデータの整合性が壊れてしまう / RailsのActiveRecordをModelと呼ぶ事は誤解を生む:tsupo2009-10-13 17:00:43
  • みんな釣られている。:H_Yamaguchi2009-10-13 15:36:54
  • Web Server側は全部 Model だと思ってる EM = Event, Model model:yappo2009-10-13 14:30:27
  • コメント欄をあとで読む:shimooka2009-10-13 14:20:41
  • そもそもMVC理解できている人が少なくて議論になってないな、コメ欄。オレオレMVC。:coppieee2009-10-13 14:05:47
  • 自分がドメインモデルをきちんと理解していないことに気づかされた。:sgtakeru2009-10-13 13:31:17
  • Model にロジックを書きやすい Rails はマシだと思うけどもなあ。:holysugar2009-10-13 13:27:39
  • もやもやしてたのがすっきりした。scaffoldでController->ARの直接操作を助長してるのが(・A・)イクナイ!!:njiro2009-10-13 13:18:31
  • 簡易さを優先したのだろうが、単に"Model"と呼んだこと自体が間違いの元なのではないかと思える:bb_river2009-10-13 12:23:59
  • GUIのMVCって、同一のモデルを異なるビューで表示できてワッショイって話じゃないのか。一方、WebのMVC Model2は、変更が入りやすいビューを分離する、みたいな話だった気が。更にレイヤー化はMVCとは別、とかなんとか。:hiyang2009-10-13 12:16:58
  • handler をただの SQL を実行するだけのもの扱いして controller にぺちぺち SQL 描く人がいるのはこのあたりが影響してるのかなぁ? しかもいろんなとこにこぴぺされるとめんてできないのです・・・ (´・ω・`;【みかん:mumincacao2009-10-13 12:10:24
  • RoRのサンプルでは確かにモデルはARのみで、コントローラにちょこちょこ書くことが多い。もちろんモデルにロジックを書くことはできる。しかし、「モデルにロジックを書く」のは語感として気持ち悪い面もある。:okusa752009-10-13 12:05:07
  • MSのDoc-View構造から入った人もいるから、歴史的にモデルとコントローラーを混同しやすいのは仕方が無いのかも。とか言いつつ、ビューにロジック書いちゃうことも。手抜きイクナイ!:cheapcode2009-10-13 11:56:48
  • WebAPIは全部モデルって事でok?:kazukiz2009-10-13 11:47:36
  • ControllerやViewが何をしでかそうともデータベースへの変更はModelが完全に一元的に担うことでデータの整合性を保障するのがMVCの意味。故にControllerやViewがデータを直接いじりまわすとかはあってはならない:hiroyuki19832009-10-13 11:45:48
  • 俺が正しい!いや俺が正しい!…。なんか宗教的な争いみたいです。:takkada2009-10-13 11:45:21
  • そのMVCはめんどくさいんだこれが:kakkunpakkun2009-10-13 11:39:03
  • MVCの本当の意味。なんとなく使ってる言葉は危険。:yyohei2009-10-13 11:01:23
  • ビジネスロジックを含むものをmodelと呼ぶ:htanabe2009-10-13 10:56:33
  • PerlでいうところのDBIx::Class操作を生でコントローラー埋め込むCatalyst Appは作るなってことですね。:lestrrat2009-10-13 10:46:55
  • "未来永劫使える概念"?:conceal-rs2009-10-13 10:46:47
  • >MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避けよう」というオブ:tarchan2009-10-13 10:30:18
  • 「Modelの外部インターフェイスの設計においてもっとも大切なことは、この「データの整合性」の責任を100%Model側で引き受け、「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておくこと」:teppeis2009-10-13 10:20:51
  • ちゃんとMVCやろうとすると難しい:yokochie2009-10-13 10:12:38
  • まあ理論からきちんと学ぶ目的だとRailsは省略できすぎて学習にならないな。分かった上で使う分には書く分量が少なくて楽。込み入ったロジックの箇所だけソースが増えるのでそうでないものに埋もれにくい。:s-tomo2009-10-13 09:48:13
  • モデルとコントローラの間にロジックっていう層が要る気がする:p4life2009-10-13 09:29:20
  • "Ruby on Railsフレームワークは本来のMVCとはほど遠い"だよねー。ARとModelが1:1に対応する訳が無い。何を思ってModelと名付けたのだろう:fukken2009-10-13 09:28:04
  • 楽しい。:kattton2009-10-13 09:14:55
  • コメント欄も:hanageman2009-10-13 08:58:30
  •  Railsにかぎらずだけど、WebのMVCとかいうやつはひどすぎるのが多い。:hirokidaichi2009-10-13 08:29:20
  • 「モデルにビジネスロジックを記述」:showyou2009-10-13 08:19:20
  • 例が / いや、仕入れと販売は業務として独立してないと大変かと....(欲を言えば会計はトランザクションの結果、在庫管理は棚卸しが...等) / Rails関係ない、というのはその辺からくることだが..:yssk222009-10-13 07:18:00
  • "ビジネスロジックがControllerに浸食していくことを意識して避けることが大切である":mollifier2009-10-13 07:15:17
  • これができてないと帳票画面を作るときに売上と在庫が一致しなくなって、文句をいうと「帳票処理対象フラグ」なんてくだらないカラムがテーブルに追加されるわけですよ。:diary1932009-10-13 06:38:19
  • ARはレコード単位での読み書き能力を持ったオブジェクトだから、複数テーブルにまたがりうるロジックを書く場合は別の層が必要になるのは必然かも。まあ「PoEAAを読みましょう」ということですね:lizy2009-10-13 04:05:24
  • コメント欄とはてブコメントも:froak2009-10-13 02:07:24
  • 米欄:aereal2009-10-13 01:45:10
  • model というとデータモデルを連想しちゃう人が多い。機能的にはStoragと言うほうがよさげ/記事中にモデルの外部IFをどう定義すればいいか例示がほしいな/wicketはどうかな?:SiroKuro2009-10-13 01:42:36
  • さっきブックマークしたSkinny Controller, Fat Modelを読めばそれでいいんじゃなかろうか:a2ikm2009-10-13 01:40:28
  • MVCのVはいいとして、MCの分離は結構もめると思う。うまくやっているソースがみたいです。特にエラー処理のところら辺。:rti77432009-10-13 01:21:17
  • controllerが厚くなるのは単にscaffoldの弊害なだけなんじゃないかなぁ。2,3本アプリ書けばControllerに書くと苦労することは身にしみるはず。:tak-n2009-10-13 01:09:01
  • なにか議論してるらしいので後で読む:sshi2009-10-13 01:06:29
  • 丁寧に設計し徹底的にテストをしなければならないのがアプリケーションの土台となるModelである。:hiroomi2009-10-13 01:00:13
  • コメント欄の議論も参考になる。Model=DAOと勘違いしてControllerにロジックを書いちゃうのが問題だとしたら、えせMVCじゃなくてCoCの弊害かもしれない。:kmachu2009-10-13 01:00:00
  • コメントも参照のこと:naoyes2009-10-13 00:45:23
  • Railsだけの問題じゃないような……。Controllerはアクションを書くから一番イメージしやすく、その流れでデータもいじっちゃいがちなのは確かだけど。/実はいわゆるController相当部にSQLべったり書いてるPHPとかよりは……:KoshianX2009-10-13 00:44:24
  • 「「えせMVC」が出来あがっちゃう弊害」ってタイトルのほうが良いんじゃ。。。:dbfireball2009-10-13 00:30:00
  • とりあえずコントローラにロジック書くのは頼むからやめようと:hirafoo2009-10-13 00:26:39
  • 確かにControllerとModelがごっちゃになってるかも知れない。:hijouguchi2009-10-13 00:23:35
  • MVC以上にビジネスロジックという言葉のいいかげんさが気に入らない:tgk2009-10-13 00:21:11
  • Plain Old〜なオブジェクトがモデルとして使えないフレームワークならフレームワーク自体の欠陥だが、Railsはそうではないので、ActiveRecordではないモデルを作らないでコントローラに押し付けるのは単なる実装者の怠慢。:rryu2009-10-12 23:54:26
  • ここに述べられてる厳密な意味で Model 設計してるパターンって少なそう。(良いか悪いかは別):suVene2009-10-12 23:47:03
  • 書いてる人が人だけになるほどなぁ的だが、モデルと現実はなぁ…。とは思う。:ya--mada2009-10-12 23:40:27
  • これはフレームワーク全般の問題でしょ。フレームワークが悪いのではなく、使う人の問題。Model=ActiveRecord「のみ」と一方的に勘違いする人がよろしくない。:masayang2009-10-12 23:35:34
  • 他のフレームワークも同じじゃね?ってみんな書いてると思うが:kno2009-10-12 23:33:41
  • controllerにばっか書いてたらあとから修正が大変ってのは経験でわかると思うんだが、学ばないのか:inarin2009-10-12 23:26:52
  • 正直、RDBのレコードをオブジェクトに自動マッピングしてくれても、なんにも嬉しくないと昔から思っている。ある程度の規模のシステムに必要なSQLはそんな単純なものじゃない。:shinfukui2009-10-12 23:22:23
  • 私はCakePHPを使っていますが、同じようなことがおきていてびっくりした。確かにControllerでデータの整合性を保っている。うーん、Cakeの場合はどうしたらよいのだろうか。:naka-06_182009-10-12 23:20:47
  • 自分がMVCについてまだ何も理解していなかったということはよくわかった:shiumachi2009-10-12 23:13:31
  • 素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装:quill32009-10-12 23:12:04
  • cakephpもsymfonyもcodeigniterもzend_controller使用時のzendもMS MVCも同じことだねぇ。:ghostbass2009-10-12 23:11:38
  • 「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ようなビジネスロジックを含んだモデルを設計しましょうね。といった話。:DameKinoko2009-10-12 23:08:58
  • Mにビジネスロジック書けば良い。ただ良くあるサンプルだとMをDAOと勘違いしやすいのも確か。:shin1x12009-10-12 23:04:45
  • ビジネスロジックはmodelに:willnet2009-10-12 22:53:16
  • タイトルがおかしい。このタイトルだとRuby on Railsで作ったものが全て「えせMVC」になると勘違いしてもしょうがない。本当に最初からコメント欄や追記で書いているような認識が十分にあったか疑問。:kei_00002009-10-12 22:51:33
  • データアクセス層をMVCのModelそのものだと勘違いしてしまうケースを指摘。:hiro_y2009-10-12 22:49:43
  • MVCアーキテクチャを理解していない開発者によって、「えせMVC」ができあがる。/これは、言語やフレームワークの問題ではなく、開発者の問題。:te2u2009-10-12 22:48:57
  • MVCのModelにとっての最大の責務は「Controllerが何をしてもデータの整合性だけは絶対に壊れない」こと。自分のソースは境界が曖昧、というかオーバーラップしているからなあ。注意。:paella2009-10-12 22:30:41
  • Modelはデータの整合性の責任も:naoto59592009-10-12 22:09:24
  • 「Ruby on Railsの上に普通にアプリケーションを作ると、ビジネスロジックをControllerに混ぜ込んで書く事になってしまい、『データの整合性』を保つことが難しくなる」:nishimotz2009-10-12 21:55:28
  • Railsでもモデルにロジックを書くと思いますが。コントローラががんばる形になりやすい傾向にある、という指摘なのかなぁ。/ 考えてみたら、paginate はコントローラに書くことになるのか。:MinazukiBakera2009-10-12 21:51:58
  • Controllerにビジネスロジックを持たせるか:shkatou2009-10-12 20:56:45
  • いわゆる「コントローラが頑張るMVC」ですな。http://www.jac-net.com/~tarzan/smalltalkers/mvc/mvc.html Small-Talkの世界でも最初はそんな感じだったと。楽なんだろうねそのほうが。何手も先読まなくても動くものができるから。:rna2009-10-12 20:53:44
  • これだけ読むとRailsはVBフォーム+ADO/DAOの二の舞ってことになるなぁ。そうなっていそうな所もあるけど、VBと同じで気づいている人はちゃんとやっているだろう。:ishisaka2009-10-12 20:53:00
  • MVCが今の時代に合致してるかの議論は誰もしないのだろうか:jar22009-10-12 20:36:13
  • FUDだよこれ。確かに初心者の人がコントローラー厚くしちゃうのはよくあるけど、Rails「でも」ふつうはそうしないって啓蒙する方が世の中はよくなると思いますよ。:moro2009-10-12 20:35:14
  • 最初の状態では何を言ってるんだかようわからんかった。追記した部分を最初から書いておくべき。誤解される書き方しといて誤解される人が多いのでとかイミフ。:akahigeg2009-10-12 20:31:51
  • 批判コメ書こうかと思ったが参考URL http://bit.ly/Sm4fS 読んで納得。AR使ってると1テーブル=1モデルという単位で考えがちになって、ビジネスロジックを置くための適切なクラスを設計する、という発想が出にくい。:serpere2009-10-12 20:18:57
  • とおりすがりがいいこと言ってる:kitaj2009-10-12 20:04:50
  • ブコメも:joan92009-10-12 20:03:09
  • MVC:saz_go2009-10-12 20:00:50
  • なんか目に見えない敵と必死になって戦ってる感のある記事。具体例を挙げないと何の説得力もないと思うけど。:oukayuka2009-10-12 19:55:31
  • 「ビジネスロジックをControllerに混ぜ込んで書く事になって」しまうのはActiveRecordを使いこなしてないため:koichiroo2009-10-12 19:54:59
  • "Modelの外部インターフェイスの設計においてもっとも大切なことは、この「データの整合性」の責任を100%Model側で引き受け、「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておくこと":JHashimoto2009-10-12 19:49:38
  • つ…釣られないぞ!:tkosuga2009-10-12 19:39:16
  • ※欄も充実:takeshiketa2009-10-12 19:20:57
  • Strutsの時も同じような議論あったよね:imai782009-10-12 19:12:48
  • あとで:ruicc2009-10-12 18:52:16
  • ここに書かれてることは増井さんと話あった結果なんだろうか?:coolstyle2009-10-12 18:43:49
  • 頭に刻んでおく>この「データの整合性」の責任を100%Model側で引き受け、「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておくこと:totttte2009-10-12 18:34:51
  • なんというかまぁ・・・:akasata2009-10-12 18:26:01
  • こいつ Rails でモノ作ったことないんじゃないか。モデルにロジック書かないでどこに書くんだよ。アホすぎる。:mrkn2009-10-12 18:24:39
  • MVC Model1 じゃないから MVC じゃないって読めて変な印象。Web は MVC Model2 でしょ:send2009-10-12 18:08:23
  • 何のためにSQLが生まれたのかをもう一度考え直したい。:kuenishi2009-10-12 18:05:04
  • トランザクションの制御(=ビジネスロジック)をモデルでなくコントローラーが担当するのならMVCではない、という話:kamataro2009-10-12 18:01:51
  • これはひどいFUD。モデルなんだからそりゃ、当然ロジックを書くんだよ。controllerのaction部は5行以上書いたら負け。が、web-MVCが本来のMVCでないのは言うまでもない:yugui2009-10-12 17:54:23
  • MVCモデルで構成するならModelありきで考えなきゃいけないけど、Microsoft Visual某とかから入ったプログラマはView中心に考えるよね。:inuz2009-10-12 17:45:06
  • え、なんで「ActiveRecord == Model」なんてところを批判の出発点にしてるの? そんなアホな。:sho2009-10-12 17:26:50
  • 『Ruby on Railsフレームワークは本来のMVCとはほど遠い」「Ruby on Railsの上に普通にアプリケーションを作ると、ビジネスロジックをControllerに混ぜ込んで書く事になってしまい、『データの整合性』を保つことが難しくなる」』:k-takahashi2009-10-12 17:26:04
  • Railsで普通にアプリを作るとデータの整合性を保つのが難しい、という話。理解してないRailsユーザもいるのかな。:IwamotoTakashi2009-10-12 17:21:56
  • HTMLを書くのがModel, Web固有の処理を書くのがController, そのほかがModelだと、最近は考えている。なかなかこう、うまいこと分割できなかったりするけど。←あ、HTMLはViewだ。:fuktommy2009-10-12 17:17:51
  • 「えせMVC解説」の問題らしい:sonota882009-10-12 16:52:34
  • mvc:tettsyun2009-10-12 16:49:56
  • 弊害っていうほどの弊害だとは思えない。自分で Model の役を担う部分をきちんと実装してあげればいいだけ。:joraku2009-10-12 16:41:53
  • わかるのだけど、実際そういう意味でのModelを必要とするのは重要ではあってもごく一部であり、全体のアーキテクチャをModel化すると頭デッカチでわずらわしいだけになってることが多いような。javaはそれがね。。:thesecret32009-10-12 16:39:43
  • 同意。Rails脳怖い。:tmatsuu2009-10-12 16:19:59
  • 真のMVCは~言語でしか実現できない話かと思ったら違った:NOV19752009-10-12 16:08:38
  • MVCの意味は時代によって変わって行ってる気もするのでよくわからない。だからどのMVCだよ、みたいな感じ。:terazzo2009-10-12 15:51:45
  • "Modelの外部インターフェイスの設計においてもっとも大切なことは、この「データの整合性」の責任を100%Model側で引き受け、「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておくこと":kodaif2009-10-12 15:50:54
  • 最近Rails(というかRuby)いじってないな。:katow2009-10-12 15:20:23
  • "整合性だけは絶対に壊れないようにModelを作っておくことが必須である":bluespear2009-10-12 15:08:35
  • すごい人がどうでもいいテキトーな話をする例:kdmsnr2009-10-12 15:04:50
  • 複雑でまともなトランザクションをやろうと思ったら隠蔽化しないでSQLを素で書いた方が簡単だったと気が付く日がくるのも遠くないでござる。テーブルの正規化もできないこんな世の中じゃポイズン。:kokorohamoe2009-10-12 15:00:05
  • cakephpも同じだ。いや、もっとひどいかもしれない。:masayki2009-10-12 14:40:54
  • とても分り易い。:sirocco2009-10-12 14:16:51
  • 確かにRailsをMVCと言ってしまうのは違和感があった。Record/Logic/Viewという感じでMVCの利点とは別の利点がある、と理解してる。:aike2009-10-12 14:12:22
  • djangoも同じだ:uemu2009-10-12 14:11:55

関連エントリ