はじめに いよいよGrailsを使ってみることにしましょう。Grailsはコマンドを使ってアプリケーションの骨格を作っていきます。基本的なコマンドの役割と、そして生成されるプログラムファイル類、それらがGrailsのアプリケーションでどのような役割を果たしているか、といった基本的な事柄について説明をしていきましょう。 対象読者 JSPを書くのは正直しんどい……と近頃感じる人。 Ruby on Railsスタイルの開発に興味があるという人。 MVCフレームワークをJavaで学びたい、という人。 Grailsの入手とインストール Grailsの記述言語「Groovy」の基本的な使い方については前回大体頭に入れることができました。今回は、いよいよGrailsに挑戦してみましょう。まずはGrailsを入手します。GrailsのWebサイトからダウンロードすることができます。 本稿執筆時点では、1.
[Ruby on Railsの「えせMVC」の弊害] というエントリが話題になっているので釣られてみます。 http://satoshi.blogs.com/life/2009/10/rails_mvc.html MVC まず結論から。Railsが本当にMVCかどうかですが、僕は真っ当なMVCだと思います。 MVCが指すもの 例のエントリの次のエントリ[O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」]で、 MVCのコンセプトは「はやりすたり」とは関係のない良いアプリケーションを設計する上での基本中の基本。Ruby on RailsやJ2EEを使ったウェブアプリケーションにも、Cocoa/UIKitの上のiPhoneアプリケーションにも通じる話だということを覚えておいてほしい。 確かにMVCは重要だけど、「「はやりすたり」とは関係のない」というのは言い過ぎだと思います。
なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが
MVC とは、もともとの出自は Smalltalk で、対話型のアプリケーションを作成するためのアーキテクチャのことでした。 Smalltalk なんて知らない人多いでしょうに、普通のプログラミングの話題でこうも顔をピョコピョコ出すのが、なんというか、憂いヤツです。そんな何かと気になるアイツこと、Smalltalk の MVC について、抜群にわかりやすいこちらの梅沢さんの記事をおすすめしておきます。 Happy Squeaking!! -オブジェクト指向再入門- [第五回：デザインパターン事始め] さて、こちらから引用して、MVC の M、V、C がそれぞれどんなモノかというと、 処理を受け持つ部分は、Modelと呼ばれます。アプリケーションで必要となる実際のデータを保持しており、業務に特化した処理を実行します。(中略) Modelの状態を表示する部分はViewになります。ビットマップデ
デブサミ２００９でid:secondlife氏が発表されたという資料を見てみました。 http://www.slideshare.net/hotchpotch/deb2009-1023281 はてぶをフルスクラッチでリニューアルした際に、従来のMVCモデルからさらに一歩進んで抽象化を進めたとのことで。 資料中、MVCの発展系として、MVACなる概念が提唱されているのですが、Aは「Applicaiont」？？「アプリケーションレイヤの作成」という記述もあるし、たぶんApplicationのtypoですねきっと。 資料からは「データソース層」「サービス層」「アプリケーション層」の３層が「Model」「View」「Application」「Controller」にどう対応するのかよくわからなかったけど、おそらく「サービス層」を担当するのが「Application」なのでありましょう。 そして、「
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
javaで実装してみた。"1."などのコメントは、エントリMVCアーキテクチャ - @katzchang.contextsの図に対応しています。 珍しくクラス図なんて書いてみたけど、こんなんでいーんでしょうか？ class user.User ユーザはMVCシステムを定義し、ビューを取り出し、ビューのボタンを押したり(1.)、ビューの内容を見たり(6.)できる。 package user; import mvc.MVC; import mvc.View; public class User { public static void main(String[] args) { MVC mvc = new MVC(); View view = mvc.getView(); System.out.println(view.display()); //prints "初期状態" //1. view
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
