Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
CSSの記述が3倍速くなる「LESS」の使い方 (1/2)
2012年02月09日 13時58分更新 文●斉藤祐也／<a href="http://css.studiomohawk.com/">CSS Radar</a> 最近のWebサイトは大規模傾向にあり、Webアプリケーションを構築する機会も増えてきました。jQueryやMooToolsなど、JavaScriptを手軽に利用できるようにするライブラリーが普及する一方、Webサイトの表示を担うCSSにも、「Blueprint」や「960 Grid System」に代表されるフレームワークが登場しています。 「LESS」や「Sass」のようなCSS拡張メタ言語は、こうしたフレームワークとは異なり、CSSの言語自体を拡張し、CSSには存在しない機能を追加するものです。CSS拡張メタ言語を利用することで、変数、ミックスイン、入れ子ルール、名前空間、四則演算、関数などの動的な処理をCSSに追加でき、CS
色々なPHPフレームワークのパフォーマンスを比較 - cakephperの日記(CakePHP, Laravel, PHP)
PHPフレームワークの速度比較では、HelloWorldを表示するのみの単純なアプリを用いた計測を元に比較表が作られることが多いです。特に後発のフレームワークは分かりやすい特徴付けとして速度をアピールする傾向にあるため、その比較表を元に N倍速いというアピールをしています。 PHPフレームワークを使うということは、DBまで絡めたWebアプリを作ることがほとんどなため、HelloWorldアプリの比較よりは、DBからレコード取得して表示するまでの処理速度を比較したほうがより現実に近い指標になると思います。特にCakePHP1系ではDBのデータ取得も独自ドライバになっていますし、モデルの処理も重いのでそこまで含めて他と比較したほうが良いと思ってます。 今回はDBから1レコード取得して表示するという簡単なアプリで各フレームワークの速度を評価しました。フレームワークに備わっているViewキャッシュ
phpフレームワークの負荷について。 月間ＰＶが数百万～１０００万程度のサイトの場合、 CakePHP等のフレームワークで実用的な「軽さ」になるのでしょうか？…
phpフレームワークの負荷について。 月間ＰＶが数百万～１０００万程度のサイトの場合、 CakePHP等のフレームワークで実用的な「軽さ」になるのでしょうか？ たとえば「人力検索はてな」が１０００万ＰＶだとすると、 Cakeでやるのは実用的なのかどうか気になりました。 できればデータを静的に保存して 表示するごとにＤＢにアクセスをやりたくないのですが、 元々あるキャッシュ機能だとＤＢアクセスする気がするので、 規模が大きくなっていくとどうなのかな、と思って悩んでいます。 イメージ的にはＭＴのように静的にデータをキャッシュしておいて、 更新部分があればそれをその都度キャッシュ更新する。 そして、ページ表示はその静的データを読み込んで表示、というイメージです。 cakePHPかphpべた書きの方がいいのか、悩んでいます。 何かアドバイスを頂けると助かります。
フレームワーク導入に備え身に着けておきたい4つの習慣 ～Ruby/Perl/PHPユーザーのためのMVCフレームワーク入門～
フレームワークを導入する前にやっておきたいこと 第2回、第3回とRuby/PHP/Perlの言語別のフレームワークを比較してきました。今回は、フレームワークを導入する前に、身に着けておきたい4つの習慣をまとめました。より良い開発工程を模索する参考となれば幸いです。 これまでの連載 第1回「効率的なWebアプリ開発の定石」 第2回「言語別フレームワークの比較」 第3回「Webサービスの開発にフレームワークが必要な理由」 1.案件について分析する Web開発では、そのサービスが『誰を対象としたものか』によって、プログラマが担う役割や作業負荷が変わります。 コンシューマを対象としたWebサイトの改変の多くは、デザイン・UIの変更です。この場合、ロジックとデザインの切り離しを行うことで、プログラマは作業負荷を軽減することが可能となります。そのため、なるべくシンプルなテンプレート構造を持ったフレーム
Grailsの登場でRuby on Railsに移行する理由はなくなった - 2009-01-23 - きしだのはてな
とか極端なことを書いちゃうと、またいろいろ怒られるわけですが。 Grailsによって、少なくともJavaプログラマがRuby on Railsに移行する理由はなくなったと言ってもいいのではないでしょうか。そして、JavaもRubyも知らない人にとっても、今からWebアプリを作成するためにどちらかを選ぶならRuby on RailsよりもGrailsのほうがいいのではないかと思います。 Grailsの価値は、もちろんRuby on RailsのようにWebアプリケーションが作成できることにあるのですが、Ruby on Railsのようなフレームワークというのは他にもあります。 実運用を前提に考えると、Grailsの本当の価値は、Java VMで動くこととSpring+Hibernateがベースになっていることであると思います。つまり、SpringやHibernateといった、Javaの世界で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
