Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Skinny Controller, Fat Model ? - noopな日々
コントローラーががんばりすぎる設計(Fat Stupid Ugly Controllers)に対するアンチテーゼとして出てきた話、"Skinny Controller, Fat Model" 元ネタ 元はこのブログ記事Buckblog: Skinny Controller, Fat Modelらしいですが、元ネタの元はこれ？http://www.amazon.com/Fat-Stupid-Ugly-Courage-Survive/dp/0757302254 さらに、http://www.survivethedeepend.com/zendframeworkbook/en/1.0/the.model#zfbook.the.model.the.fat.stupid.ugly.controllerここでも語られていました。 それが推奨される理由として、 FSUCに傾倒する理由として、コントローラ
Zend_Formで実現できるMVC粒度の調整 - noopな日々
MVCの分離（初期） ソフトウエア開発の基本の一つに、MVCの分離がある。 PHPは１ファイル中で完結させることも可能なテンプレートスクリプト（異論はあるかもしれない）である。さらに効率的なテンプレートエンジンが開発され、プログラムをMVCに分離して保守性の向上が図られた。MVC構成によるアプリケーションが一般的となった。 しかし、一部にはコントローラーでリクエストを受け取り、データを準備してビューに渡すという典型的なパターンがMVCのゴールであると誤解されている節がある。 さらなる大型化、高機能化 システム全体で几帳面なMVC分離を考えると、コヒージョンの低下を招き、結果として、スクリプトが分離されているのに、それぞれの結合度が高くなってしまう現象が発生する。 たとえば、アプリケーションのディレクトリ構造をMVCに切って、すべてのスクリプトをその構成の中にカテゴライズしたとする。すると複
MVCとPAC - noopな日々
Presentation-Abstract-ControllerとModel-View-Controllerについてさらっと言及 MVCアーキテクチャはある程度の規模になると限界が訪れる。 http://c2.com/cgi/wiki?RecursiveModelViewController http://d.hatena.ne.jp/noopable/20090127/1233014697 この、1999年の記事でPACについて触れられているが、PACはMVCのスケール問題、その他を解消しうる。MVCでも、RecursiveMVCでMVCに階層構造を持ち込んで解決するという方法もあるらしい。 http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#fig:pac 似たようなことは誰でも一度は考えることだろう
内部WebAPIの呼び出しコスト - MVCモデルの”次” - Tous Les Jours 攻防記
デブサミ２００９でid:secondlife氏が発表されたという資料を見てみました。 http://www.slideshare.net/hotchpotch/deb2009-1023281 はてぶをフルスクラッチでリニューアルした際に、従来のMVCモデルからさらに一歩進んで抽象化を進めたとのことで。 資料中、MVCの発展系として、MVACなる概念が提唱されているのですが、Aは「Applicaiont」？？「アプリケーションレイヤの作成」という記述もあるし、たぶんApplicationのtypoですねきっと。 資料からは「データソース層」「サービス層」「アプリケーション層」の３層が「Model」「View」「Application」「Controller」にどう対応するのかよくわからなかったけど、おそらく「サービス層」を担当するのが「Application」なのでありましょう。 そして、「
MVCパターンとPACパターン - みるくCocoa
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
MVC - MVCとはModel-View-Controllerの頭文字をとったものです。
MVC - MVCとはModel-View-Controllerの頭文字をとったものです。 目次 新着情報2004 MVC関連リンク MVCと３層C/S 関連モデル PAC - Presentation - Abstraction - Controller Document - View architecture MVC発祥の地では 雑談 MVCとはModel-View-Controllerの頭文字をとったものです。 新着情報2004 月刊DBマガジン6月号にModel2+の解説があるらしい。（ニュースソース[jfriends-ml 11123] Model2+） MVC関連リンク MVCモデルという言葉をよく聞きますが何のことですか？ http://www.atmarkit.co.jp/fjava/javafaq/j2ee/j2e07.html 使わないと損をするModel-View
CatalystのModelの話 - Charsbar::Note
「なんでＭＶＣなんて使うの？」という牧さんの記事には全面的に賛成なわけですが、ここでCatalystを出してくるんだったらひとつDISっておかないといけないものがある。 Catalyst::Model::DBIC::SchemaとかCatalyst::Model::Jifty::DBIとか、O/Rマッパをそのままモデルにしちゃってるヤツだ。 自分でも書いておきながら何を、と思わんではないけれど、MVCのキモは、Mで起こっていること、Cで起こっていること、Vで起こっていることをそのまま相手に見せてはならない、ということ。 CatalystのCはMの要素とVの要素を併せ持たされてしまうことが多いわけですが、MVC的には、ふつうの人がC（やV）でやっていることのほとんどはMの中に戻してやらないといけない。O/RマッパはあくまでもMのなかでこっそり使うものであって（現代的にはMMVCパターンの一方
CatalystとMVCとSoozyと切なさと(まとめリンクもあるよ) - Yappo::タワシ
今空前のCatalyst MVCブームなのでSledgeを劣化させたSoozyにCatalystの実装を書いた身として書いとく。 ModelにDBICをそのまま使っちゃってる時点で何だかモデルじゃないし、何でかControllerにロジックが入ったりとか、酷い時にはViewであるTTのtemplate fileにロジックが入ってしまったりとか酷い事になっている今日この頃。(それはSoozyとしての設計ミスっぽい所もあるけども) 有る意味Catalyst本体がControllerであって、CatalystのControllerであるというみかたもできるとかどっかで言ってた記憶もあるなと。 ちょっと微妙に違うか。 CatalystはControllerでCatalystのController(MyApp::Controller)は、それを拡張する為のプラグインのような物か。 miyagawaさ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ＭＶＣのモデルはDBじゃなくてもいいんだよ - D-6 [相変わらず根無し]
ＭＶＣのモデルはDBじゃなくてもいいんだよ id:charsbarさんが、先ほど書いたエントリに関して 後半その通りなわけですが、CatalystはModel::DBIC系のせいでMVCが誤解されてるのよねー と言っておられる。たしかにその通り。「モデルってDBでしょ？」みたいな印象が一般的にあると思う。 そういう印象を持ってる人に説明すると、「モデルを作る」って何かというと、DBのようなストレージにあるものをどうこうする、ではなくて「データに対する操作を抽象化したものを作る」ということです。例えば、ブログを作ると、Blog、BlogEntry、BlogUserみたいなモデルを作ります。そしてその操作方法はこんな感じ： # ブログを登録するみたいなAPI MyApp::Model::Blog->create({ user => $blog_user, title => $title, .
PHP Zone » Top 10 PHP MVC frameworks
Captcha security check mustap.com is for sale Please prove you're not a robot View Price Processing
MVC and Web APIs: blog.bulknews.net
MVC and Web APIs naoyaのはてなダイアリー - MVCフレームワークにおける Web API 実装 Sledge における Web API (XML-RPC/AtomPP) のハンドリングについての言及がありました。これからの MVC フレームワークに求められる必要条件の一つとしてこの Web API を処理しやすいかどうかというのは重要な気がします。 MVC フレームワークと Web APIs (XML-RPC, REST, SOAP) な話。 Catalyst や Sledge なんかの XML-RPC 実装なんかもプラグインででてきていて、Sledge::Plugin::XMLRPC は CPAN から入手できるわけですが（グッジョブ！）、どうも利用者側の実装方法が若干スマートにならない気がしています。 というのは、 use Sledge::Plugin::XML
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Django の設計思想