サーバーサイドのＪａｖａのStruts2を使用した開発のクラス分けについて

質問

表題の件で、ご質問なのですが、今現在、HTML、JavaScript,Struts2,Java（strutsのアクションクラスはサーブレットとは別ですかね？サーバー側で動くＪａｖaプログラムという事でサーブレットでよろしいですか？）を使用して簡単にですが、フォームで入力された値を、ＤＢに登録し、登録結果をブラウザに表示するというのを作ろうと考えています。
　そこで、それぞれの機能を、どのクラスに分担させるかを考えているのですが、全く思いつきません。なるべくＭＶＣモデルに準拠し、効率のよい形にしたいのですが、サイトで参考になるサンプルを探しも見つかりませんでした。
　設計する人によって変わると思いますが、どなたか、例をあげていただけませんでしょうか？
* 検索クラス　セレクトを発行するクラス等

回答No.3

gwagaw

サーブレットってことで考えるならseaserのサンプルでも落としてみてはかが、おいらが新規開発するときは大体あんな感じです。でもMVCの意味を知らないアホなので検討違いかも？

フォームで入力された値を、ＤＢに登録し、登録結果をブラウザに表示するのであれば例えばですけど、こんくらいあればいいんじゃないですかね？

|--action(サーブレット)
|--form(リクエストを受け取る)
|--dto
| |--entity(DBに登録する際のentity)
|--logic(登録する機能)

え？質問の意図と全然ちがうと・・・？すみません。

参考URL：

http://s2struts.seasar.org/ja/1.2/index.html

回答No.2

noname#94983

>サーブレットも十分機能ごとに縦割り可能だったと思います。

まったくその通り。ただし、これは「プログラマが意図的にそう作ればそうなる」ということであり、プログラマに依存する。「誰が作っても、こういう設計で出来上がる」というわけではない。フレームワークは、誰が作っても、ビューJSPとアクションといった形で分離された形で作られる。この違いだろう。

また、入力のチェックやフィルター処理など、毎回似たようなものを作るより、フレームワークで自動的に処理してくれたほうが楽なのは確かだ。そういった意味で、「いろいろ複雑なことを考えると、一から作るよりフレームワークを使ったほうが早い」ということだろう。

>この疑問を解消してください。

もともと、Strutsというのは、まだフレームワークなどというものがなかった時代に登場した、MVCフレームワークの元祖のようなもの。で、この当時の最大の問題は、「JSPによるビューとビジネスモデルの分離」だった。つまり、JSPで、１つのページの中に表示出力も内部処理もごちゃごちゃに書いてしまい、後で収拾がつかなくなる、というのをなんとかしたかった。

で、Strutsによって、「JSPはビューのみ、ビジネスロジックはアクション」と切り分けて開発できるようになった。この当時としては、これはこれで意味があった。現時点でも、この分離は非常に重要だと思う。

ただし、Strutsはそこばかりを意識したためか、データベース管理をする「Model」の部分がすっぽり抜け落ちている（意図的になくしたのか、よくわからないが）。このため、MVCモデルのはずが、VCモデルだけになってしまっている。結局、データベースがらみは全部自分で実装しないといけないわけで、それで「何のためにこんな複雑なフレームワークを使うのか？」という感じになってるんだと思う。

第２世代というか、新世代のフレームワークは、やはりRuby on Rails登場以後のものといっていい。これらは、データベースアクセスを一元化するModelの機能が標準で実装されており、利用するデータベースの設定を書き、テーブルにアクセスするためのモデルを定義するだけで、あとはメソッドを呼ぶだけでモデルから必要なレコードがオブジェクトの形で得られる。先に回答したモデルの部分が、最初から標準ではいっているわけだ。

更に、Rails以降では、いわゆる「スカッフォールディング」という機能が用意されている。これは、いわば「骨組み作り」の機能で、コマンド一発でCRUDの基本ページが自動生成される。もちろん、モデルやアクションもすべて自動的に作られる。データベースを利用した開発では、まずスカッフォールディングでCRUDのページを自動生成し、後はそれを少しずつアレンジしていけばいい。

ここまできて、初めて「MVCフレームワークは、こりゃあ便利だ。開発効率が飛躍的にアップする」となる。なにしろ、基本的な設計から基本ページ、アクション、モデル作成まですべてフレームワークが自動で用意してくれるんだから。更に基本設計もこの段階で出来上がっているわけで、一から作る場合を考えると、だいたい７合目ぐらいまでは既に出来上がってる感じになる。

Strutsは、そういう「本当に使えるようになったMVCフレームワーク」が誕生する前の、その土台となった時代のフレームワークだといっていい。だから、中途半端に便利で、中途半端に不便だ。Strutsでやってくれるのは、せいぜい３合目ぐらいまでの機能かも知れない。

ところが、非常に初期の段階でStrutsが登場し、他に対抗馬がなかったためにば～っと広まったため、Javaの世界においては、第２世代のRailsなフレームワークがなかなか登場しない。（これは、ソースコードを自動生成するだけでシステムが完成できるスクリプト言語と、Javaのようなコンパイラ言語との違いもあると思うが）

また、この一番のネックとなる「データベースアクセス」の部分をなんとかするため、「O/Rマッピング」というフレームワークが登場した。Hibernateなどだが、これによりStrutsなどは「その部分はHibernateにまかせた」という形になった。O/Rマッピングを組み合わせてStrutsを使えば、データベースアクセス部分もかなり便利になるんだが、そのために、逆に「Struts自身の進化」はうやむやになってしまった。

どうも、Javaの伝統なのか、さまざまなライブラリやフレームワークを自分なりに組み合わせて一つのシステムを作るというアプローチが王道で、「全部、これ１つですっきりくっきり」といった方向にはあまりいかないようだ。Eclipse的に「基本となる土台があるから、後は自分でいろいろ組み合わせて使う」という感じで、NetBeansのように「最初から何もかも全部入ってます」というのはなぜか敬遠される気がする。

というわけで、現在は、Strutsだけで作るということはあまりないと思う。最低でもStruts + O/Rマッピングソフト、という感じなんだろう。また最近は、ベースはSpringやSersar2で、GUIとアクション部分をStruts、データベースアクセスをO/Rマッピングという形で組み合わせて開発することも多いと思う。

いわば、Javaの世界においては、Strutsは既に「部品の一つ」に過ぎない感じになっているんだろうと思う。その部品だけでは不便だが、そうした部品をいくつも使いこなせるようになれば、自在にシステムを組み立てられるようになる、という感じだろう。逆にJava以外の世界（PHPとかRubyとか）では、全部をワンパッケージにしたようなMVCフレームワークが主流になっている。これだと１つ覚えればそれでオッケーだが、逆に「データベースアクセスの部分は使いにくいからこっちにしたい」ということはできない。まぁ、どっちを選ぶか、ということなんだろう。Javaの世界は「さまざまな部品の組み合わせ」方式を選んだ、ということだろう。

回答No.1

noname#94983

データベースアクセスだと、一般にCRUDというのが基本機能となる。Create,Read,Update,Deleteのこと。まずは、この４つの機能をそれぞれサーブレットなどで整理するということになると思う。Struts2であれば、それぞれをアクションとして整理することになると思う。

それほど複雑な機能でなければ、アクションの中で、基本的な処理とデータベースアクセスはまとめてしまうと思う。データアクセスを切り離して整理したい、というのであれば、Beanとしてデータベースのモデルクラスを定義し、そこにすべて預ける、というのが一般的じゃないだろうか。

つまり、CRUD機能およびテーブルの構造をもったモデルクラスを定義し、先ほどの４つのアクションからは単にモデルクラスのメソッドを呼ぶだけにしておく。データアクセスをモデルクラスにまとめることで、アクション側は非常にシンプルになるはず。

また、扱うレコード情報は、O/Rマッピングのように、Javaのオブジェクトとして扱えるようにしておく。つまり、たとえばモデルクラスのレコード取得メソッドを呼び出すと、レコードクラスのインスタンスが配列として返される、というような形で定義しておく。生のレコードデータでなくJavaのオブジェクトとしてやりとりできるようにしておくことで、更にアクション側の処理は見通しが良くなる。

というわけで整理すると、ざっとこんな感じだろうか。

・モデルクラス。Beanとして定義。データベースへのCRUDメソッドを持つ。またやり取りされるレコードは、Javaのオブジェクトとして扱われるように定義する。

・アクションクラス。CRUDの各機能ごとに用意する。これらは各機能のためのビューであるJSPページがあり、そこからそれぞれのアクションが呼び出されると、その内部からモデルクラスのメソッドを呼び出して必要な処理を行うようにする。

お礼

抽象的な質問で回答つかないかとあきらめていたのに、ご回答くださりありがとうございます。
とてもわかりやすい説明で、助かりました。
回答ついでで恐縮ですが、出来れば疑問点にお答え願いたいのです。
最近、サーブレット中心から、strutsの中心の学習を始めたのですが、strutsを使うメリットがあまり思いつきません。というのも、サーブレットも十分機能ごとに縦割り可能だったと思います。
他にも、なにかメリットがあればよいのですが、strtutsは、requestデータがない分文字化けが起きるカ所などが増え、非常にやりづらく感じています。
　世間では、標準的だといわれているので、なぜという疑問しか残りません。この疑問を解消してください。