サーバーサイドのJavaのStruts2を使用した開発のクラス分けについてこんにちはゲストさん。>>締切り済みの質問サーバーサイドのJavaのStruts2を使用した開発のクラス分けについて表題の件で、ご質問なのですが、今現在、HTML、JavaScript,Struts2,Java(strutsのアクションクラスはサーブレットとは別ですかね?サーバー側で動くJavaプログラムという事でサーブレットでよろしいですか?)を使用して簡単にですが、フォームで入力された値を、DBに登録し、登録結果をブラウザに表示するというのを作ろうと考えています。そこで、それぞれの機能を、どのクラスに分担させるかを考えているのですが、全く思いつきません。MVCモデルに準拠し、効率のよい形にしたいのですが、サイトで参考になるサンプルを探しも見つかりませんでした。回答(3)ANo.3gwagawサーブレットってことで考えるならseaserのサンプルでも落としてみてはかが、おいらが新規開発するときは大体あんな感じです。|--entity(DBに登録する際のentity)|--logic(登録する機能)え?質問の意図と全然ちがうと・・・?すみません。(0)通報するANo.2noname#94983>サーブレットも十分機能ごとに縦割り可能だったと思います。これは「プログラマが意図的にそう作ればそうなる」ということであり、プログラマに依存する。「誰が作っても、こういう設計で出来上がる」というわけではない。フレームワークは、誰が作っても、ビューJSPとアクションといった形で分離された形で作られる。入力のチェックやフィルター処理など、毎回似たようなものを作るより、フレームワークで自動的に処理してくれたほうが楽なのは確かだ。いった意味で、「いろいろ複雑なことを考えると、一から作るよりフレームワークを使ったほうが早い」ということだろう。>この疑問を解消してください。Strutsというのは、まだフレームワークなどというものがなかった時代に登場した、MVCフレームワークの元祖のようなもの。この当時の最大の問題は、「JSPによるビューとビジネスモデルの分離」だった。JSPで、1つのページの中に表示出力も内部処理もごちゃごちゃに書いてしまい、後で収拾がつかなくなる、というのをなんとかしたかった。Strutsによって、「JSPはビューのみ、ビジネスロジックはアクション」と切り分けて開発できるようになった。この当時としては、これはこれで意味があった。現時点でも、この分離は非常に重要だと思う。Strutsはそこばかりを意識したためか、データベース管理をする「Model」の部分がすっぽり抜け落ちている(意図的になくしたのか、よくわからないが)。このため、MVCモデルのはずが、VCモデルだけになってしまっている。結局、データベースがらみは全部自分で実装しないといけないわけで、それで「何のためにこんな複雑なフレームワークを使うのか?」という感じになってるんだと思う。Rails登場以後のものといっていい。これらは、データベースアクセスを一元化するModelの機能が標準で実装されており、利用するデータベースの設定を書き、テーブルにアクセスするためのモデルを定義するだけで、あとはメソッドを呼ぶだけでモデルから必要なレコードがオブジェクトの形で得られる。先に回答したモデルの部分が、最初から標準ではいっているわけだ。Rails以降では、いわゆる「スカッフォールディング」という機能が用意されている。これは、いわば「骨組み作り」の機能で、コマンド一発でCRUDの基本ページが自動生成される。モデルやアクションもすべて自動的に作られる。データベースを利用した開発では、まずスカッフォールディングでCRUDのページを自動生成し、後はそれを少しずつアレンジしていけばいい。ここまできて、初めて「MVCフレームワークは、こりゃあ便利だ。開発効率が飛躍的にアップする」となる。基本的な設計から基本ページ、アクション、モデル作成まですべてフレームワークが自動で用意してくれるんだから。基本設計もこの段階で出来上がっているわけで、一から作る場合を考えると、だいたい7合目ぐらいまでは既に出来上がってる感じになる。Strutsは、そういう「本当に使えるようになったMVCフレームワーク」が誕生する前の、その土台となった時代のフレームワークだといっていい。中途半端に便利で、中途半端に不便だ。Strutsでやってくれるのは、せいぜい3合目ぐらいまでの機能かも知れない。ところが、非常に初期の段階でStrutsが登場し、他に対抗馬がなかったためにば~っと広まったため、Javaの世界においては、第2世代のRailsなフレームワークがなかなか登場しない。(これは、ソースコードを自動生成するだけでシステムが完成できるスクリプト言語と、Javaのようなコンパイラ言語との違いもあると思うが)また、この一番のネックとなる「データベースアクセス」の部分をなんとかするため、「O/Rマッピング」というフレームワークが登場した。Hibernateなどだが、これによりStrutsなどは「その部分はHibernateにまかせた」という形になった。O/Rマッピングを組み合わせてStrutsを使えば、データベースアクセス部分もかなり便利になるんだが、そのために、逆に「Struts自身の進化」はうやむやになってしまった。Javaの伝統なのか、さまざまなライブラリやフレームワークを自分なりに組み合わせて一つのシステムを作るというアプローチが王道で、「全部、これ1つですっきりくっきり」といった方向にはあまりいかないようだ。Eclipse的に「基本となる土台があるから、後は自分でいろいろ組み合わせて使う」という感じで、NetBeansのように「最初から何もかも全部入ってます」というのはなぜか敬遠される気がする。いうわけで、現在は、Strutsだけで作るということはあまりないと思う。O/Rマッピングソフト、という感じなんだろう。最近は、ベースはSpringやSersar2で、GUIとアクション部分をStruts、データベースアクセスをO/Rマッピングという形で組み合わせて開発することも多いと思う。Javaの世界においては、Strutsは既に「部品の一つ」に過ぎない感じになっているんだろうと思う。その部品だけでは不便だが、そうした部品をいくつも使いこなせるようになれば、自在にシステムを組み立てられるようになる、という感じだろう。逆にJava以外の世界(PHPとかRubyとか)では、全部をワンパッケージにしたようなMVCフレームワークが主流になっている。これだと1つ覚えればそれでオッケーだが、逆に「データベースアクセスの部分は使いにくいからこっちにしたい」ということはできない。どっちを選ぶか、ということなんだろう。Javaの世界は「さまざまな部品の組み合わせ」方式を選んだ、ということだろう。(0)通報するANo.1noname#94983データベースアクセスだと、一般にCRUDというのが基本機能となる。Create,Read,Update,Deleteのこと。この4つの機能をそれぞれサーブレットなどで整理するということになると思う。Struts2であれば、それぞれをアクションとして整理することになると思う。それほど複雑な機能でなければ、アクションの中で、基本的な処理とデータベースアクセスはまとめてしまうと思う。データアクセスを切り離して整理したい、というのであれば、Beanとしてデータベースのモデルクラスを定義し、そこにすべて預ける、というのが一般的じゃないだろうか。CRUD機能およびテーブルの構造をもったモデルクラスを定義し、先ほどの4つのアクションからは単にモデルクラスのメソッドを呼ぶだけにしておく。データアクセスをモデルクラスにまとめることで、アクション側は非常にシンプルになるはず。扱うレコード情報は、O/Rマッピングのように、Javaのオブジェクトとして扱えるようにしておく。モデルクラスのレコード取得メソッドを呼び出すと、レコードクラスのインスタンスが配列として返される、というような形で定義しておく。生のレコードデータでなくJavaのオブジェクトとしてやりとりできるようにしておくことで、更にアクション側の処理は見通しが良くなる。いうわけで整理すると、ざっとこんな感じだろうか。