- - PR -
なぜBeanなの？
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2002-07-17 22:27
昔から思ってた素朴な疑問なのですが･･･。
Servletから呼び出すビジネスロジックはなぜBeanでなければいけないのでしょうか？ 普通のClassを使用することとの違い（メリット）が分からないのですが･･･。 （というかその呼び出すBean自体もただ単にSerializableになっているだけで、 Beanというのもおこがましいような気が･･･） どなたか説明していただける方いませんか？ |
|
投稿日時: 2002-07-18 09:36
Javaプログラマでない人が統一的な方法で簡単にJavaオブジェクトを操作できるようにするためでしょう。そのためにBeanアクセス専用のタグを用意しているのだと思います。
>というかその呼び出すBean自体もただ単にSerializableになっているだけで、 >Beanというのもおこがましいような気が･･･ いえ、JavaBeanではget/settのパターンでメソッドが定義されますから、プロパティの読み書きをする感覚でオブジェクトを操作することができます。 #個人的には、JSPのように専用タグを使うより、Jakarta Velocityで採用されている$myobject.propetyのような単純な形式の方が好みです。 [ メッセージ編集済み 編集者: miki 編集日時 2002-07-18 09:42 ] |
|
投稿日時: 2002-07-18 09:46
私としては、呼び方の問題だけのような気がしますが。
全てのクラスはある意味Beanだと思います。 シロート考えですか？ 私の理解では 「あるクラスが、プロパティとそれに対するアクセサメソッドが命名規則にしたがって定義されていれば、そのクラスはBeanだ」 と思ってますが、誤解があるのでしょうか。 （Serializableである必要なんてありましたっけ？） もし、BeanをEJBの意味で使ってらっしゃるなら、分散オブジェクトの実現やトランザクション管理とかが意識せずにできるっていうのがメリットになると思います。 |
|
投稿日時: 2002-07-18 11:11
webアプリを勉強しながら プロトタイプを作成していますがＷＥＢアプリで普通のクラス？
は使えないと思い込んでましたが、ちゃんと使えるんですね、驚きました。 だって webアプリの入門書では jsp servlet bean ejb の組み合わせは出てくるけど 通常の無印？のクラスはあんまりでてこないですからね |
|
投稿日時: 2002-07-18 12:34
>Servletから呼び出すビジネスロジックはなぜ...
JSPのつもりで返信してました。あぁ、恥ずかしい。 ただ、言い訳になりますが、MVCモデルにおいて各構成要素を次のようにマッピングすると仮定すると、JSPからアクセスされることを前提にModelをBeanの形式に統一しておくことは一理あります。 Model -> Bean (JavaBean, EJB) View -> JSP Controller -> Servlet このようなJSPとServletの併用という構成では、Servletでデータ処理をおこない、それをBeanにまとめ、JSPで表示することができます。ServletだけではBeanのメリットを感じないかも知れませんが、オブジェクトの引き渡しや共有の単位としてはBeanは意味があります。 それから、Beanというと一般的なクラスというより、jarに固めた再利用可能なコンポーネントというニュアンスが強くなると思います。たとえば、JavaBeanの場合、アプリケーションをWebアーカイブとしてまとめるときも、必要なBeanのjarを選択してWEB-INF/libに入れることができます。 また、Beanのget/setのメッセージパターンは、プログラムからBeanにアクセスするときにインタフェース上統一的にアクセスできますから便利です(リフレクションを使います)。つまり、Beanの形式にしておけば、いろいろなWeb関連のツールや言語を利用しやすいというメリットもあります。 たとえば、Beanを参照できる言語を考えたとき、$myobject.property = "test"のような記述を許すためには、Beanのような形式は処理を単純化するために重要です。たとえば、前の返信で触れた、Velocityはオブジェクトのプロパティアクセスが可能ですが、このBeanのgetter/setterがあればこそこのような簡便なアクセスが可能になっています。 |
|
投稿日時: 2002-07-18 13:02
>「あるクラスが、プロパティとそれに対するアクセサメソッドが命名規則にしたがって定義されていれば、そのクラスはBeanだ」
違います。 シングルトンパターンなどのために、インスタンスの生成を制限しているようなクラスや、 引数がないとインスタンスが生成できないクラスはBeanではありません。 引数なしのpublicコンストラクタがなければ、<jsp:useBean>による指定がされていても コンテナはインスタンスを生成できません。 スクリプトレットでガシガシ書くならそれでもかまいませんが、JSPの利点を最大限に活用して タグベースで簡潔に書くためには、Beanの形式を守る必要があります。 <jsp:useBean id="hoge" class="HogeHoge" /> というアクションは、 <% HogeHoge hoge = new HogeHege(); %> 以上の機能を有します。 すなわち、裏にscope="request"が暗示されているわけで、あったらそれを使う、なかったら 生成するというように。scope属性を適宜設定(request,application,session,page)すれば、 より多彩に利用できます。 <jsp:useBean id="hoge" class="HogeHoge" scope="session"> <jsp:useBean id="boke" class="BokeBoke"/> </jsp:useBean> と書けば、セッションにhogeが登録されていれば、それを使い、なければHogeHogeのインスタンスを 生成して、hogeとしてセッションに登録し、さらにBokeBokeのインスタンスを生成して、bokeとして リクエストに登録します.これをスクリプトレットで書いたら何行になりますか? >（Serializableである必要なんてありましたっけ？） 場合によります。基本的にはあります。 しかし、Serializableでなくとも使えるか否かは実装に依存します。 なぜなら、 <jsp:useBean id="hoge" beanNames="HogeHoge" type="HogeHoge" /> と記述した場合、コンテナはまずリソース "HogeHoge.ser" から直列化されたオブジェクトの読み込み、 なければHogeHogeクラスをロードして、そのクラスのインスタンスを生成するからです。 _________________ Paul K.Nakagome |
|
投稿日時: 2002-07-18 13:28
nakagomeさん
ありがとうございます。 コンテナが裏でしてくれていることに対する理解、つまりはJSP,Servletの仕組みの 理解が不足（というか皆無）してることに気づきました。 便乗して質問ですが、 「Serializable であることは基本的に必要」 とのことですが、明示的に implements Serializable ってしていなくてもいいんですか？ 「基本的」である割にそうしているものが私が見た限り少ないので。 |
|
投稿日時: 2002-07-19 00:02
皆さん答えてくださってありがとうございます。
（たった１日でこんなにレスが来るとは思っていませんでしたが） JSPタグとの絡みで考えるのが一番「なるほど」と納得できますね。 確かにServletからビジネスロジックを呼ぶだけの場合は通常のクラスとの違いがはっきり しませんが（特に業務メソッドのみを実装したStateless的Beanを作成した場合）、 MVC全体から鳥瞰した場合には、オブジェクトの受け渡しとしてBeanが「部品」の単位として 各レイヤで引き渡されて共有されているというイメージが湧きます。 ところで、サーバサイドのBeanの条件は、 １．Serializableインターフェイスを実装している ２．引数なしコンストラクタがある ３．getter/setterアクセサメソッドが存在する でしたっけ？ 普通のクラスとサーバサイドBeanの明確な（規約としての）違いってないような･･･。 |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。