先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
以下のエントリを拝見させて頂いて、思った事のメモ。 ＭＶＣのモデルはDBじゃなくてもいいんだよ - D-6 相変わらず根無し 個人差があるかとは思いますが、Catalyst を使っていると、 C のテストを書く行為を、私は、そんなに苦に感じない。ただ、C は URI リソースと M を繋ぐラッパと割り切り、複雑なビジネスロジックは M に押し付ける方が、コードがスッキリするし、M 自体を汎用的にできそう。 ＭＶＣのモデルはDBじゃなくてもいいんだよ - D-6 相変わらず根無し じゃあ元々のブクマコメントのModel::DBICはどうすんだよ、いらないのかよ、みたいなところに行き着くかと思うのだが、そこはそれ、モデルに「格納先」を指定するのにDBを抽象化したModel::DBICを使ってやる、っていう手もある my $c = shift; # Catalyst的なcontextがあると仮定
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Catalystは、Maypole 3.0になりそこねたものだということ。 当時Maypoleのメンテナだったsriが、Railsにかぶれた挙げ句新しいMaypoleの構想をぶちあげて、もともとの作者である（こないだKansai.pmで話をした）Simon Cozensに「それMaypoleじゃないから」とダメだしを食らって、「じゃあこっちで勝手にやるもんね」とフォークしたのがCatalystである、ということ。 だからこそCatalystの初期バージョンは2.99から始まるということ。 その意味で、Maypoleの文脈なら問題ないことでも、Catalystの文脈ではかならずしも正しいとは限らないということ。 もちろんCatalystも、sriが実質けり出されていまは集団指導体制になっているから、当初の文脈とはかなり異なってきているわけですが、やっぱりCatalystは、（Maypole的
今空前の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日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
バグ見つけた→それってどんなテスト？もしくは、なんでＭＶＣなんて使うの？ 最近ソフトウェアエンジニアリングに置ける開発手法に関して考えている。 ぶっちゃけ言ってしまうと「やっぱりTDDっぽいのがいいな」というところに落ち着きつつあるのだが、厳密にTDDをしたほうがよい、と思ってるわけではない。TDDとかExtremeプログラミング、Agileプログラミングにしても理想はいいんだけど、原理主義っぽい使い方は現実にそぐわないと思ってるからだ。 前置きはこれくらいにしておいて・・・重要だと思うのは以下の点： 開発サイクルに自動テストツールを組み込むエンジニアによるバグ／不具合発見時には「動かない」は許可しない。必ず再現コードを提出してもらうテストを自動テストツールを組み込む（＝次回リリース前にはかならずテストを実行できる状態にする）テストが通るまで修正を続けるという開発サイクルを取るべきだ、とい
「なんでＭＶＣなんて使うの？」という牧さんの記事には全面的に賛成なわけですが、ここで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パターンの一方
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
本来、MVC の M はロジックを含み、C はイベントハンドリング、ウェブアプリケーションでいえば、画面遷移のみを担当します。 Catalyst でスキーマローダーをつかって、MyApp::Model::XXXX を自動生成してしまうと、「テーブル：モデル＝１：１」という COBOL 全盛期みたいなアーキテクチャになってしまいます・・。それで、仕方なくロジックを C に書くようにすると、C が見るも無残なほど膨れ上がってしまい、メンテナンスの困難な製品ができあがります（笑）。Rails や Catalyst でも、こういう作り方を推奨している雰囲気があります。 「テーブル：モデル＝１：１」が許されるのは、Rails や Catalyst で本当に小さいアプリケーションを作るときまでで、多少大きいアプリケーションを作ろうと思ったら、MyApp::Model::XXXX を自動生成するなら、M
ＭＶＣのモデルはDBじゃなくてもいいんだよ id:charsbarさんが、先ほど書いたエントリに関して 後半その通りなわけですが、CatalystはModel::DBIC系のせいでMVCが誤解されてるのよねー と言っておられる。たしかにその通り。「モデルってDBでしょ？」みたいな印象が一般的にあると思う。 そういう印象を持ってる人に説明すると、「モデルを作る」って何かというと、DBのようなストレージにあるものをどうこうする、ではなくて「データに対する操作を抽象化したものを作る」ということです。例えば、ブログを作ると、Blog、BlogEntry、BlogUserみたいなモデルを作ります。そしてその操作方法はこんな感じ： # ブログを登録するみたいなAPI MyApp::Model::Blog->create({ user => $blog_user, title => $title, .
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
