『ポストRailsと個人的に期待するPlay frameworkを推奨する5つの理由』
エンタープライズ・アプリケーションの分野ではJava EEがほぼデファクトになっていると言っても過言ではありません。堅牢性やスケーラビリティを備えたインフラが整っており、大規模な環境における実績も豊富です。 一方、Webアプリケーションの分野では人気はいま一つです。その理由は、Java EEの重そう・めんどくさそうという印象だと思います。JavaでWebアプリケーションを作るには基本的にはServletやJSPを使いますが、これらは大規模システムや複雑なトランザクションまでも想定したJava EEによるものなので、手っ取り早くさくっとWebアプリを作りたいというライト層には敬遠されます。 Java の世界でも、StrutsやSpringを始めとしたMVCフレームワークが登場してきました。しかし、これらはどれもJava EEをベースにしており、かつアプリを動かすまでに多くの設定が必要になりま
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
