スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ブログに足りないもの

ブログは、普通のWeb日記に加えて、コメントやトラックバックがあることから、多くの人に広まっていった感じがするのだが、ときどき足りないと思うものがある。

コメントやトラックバックは、他人の記事に対して書くもので、あくまでもその人の記事が主である。その人に対して、こちらから話題を提供したい場合、今のブログのシステムでは、私が知っている限りではできない。メールを送るのでは、一対一になってしまい、公開したい内容でもそうできない。

なので、訪問者主導型の掲示板みたいなものがあればいいと思う。訪問者じゃなくて当人が始めてもよいが。公開質問受付みたいに。

これは特に、フリーランスセミナーをしていたY氏のブログのとき、そう思った。質問を受け付けるといっても、どこに書けばいいのかわからない。適当にもっとも近いブログ日記を探して、そこのコメントに書き込んだような感じだった。ブログブームに乗って何でもブログでというノリだったが、このシステムではフィットしない。

通常のブログは、やはり日記なので、あるトピックを継続させたい場合には合わない。かといって一般の掲示板だと、公共性が大きすぎる。その中間で、ブログに付随する簡易掲示板みたいなものがほしいと思う。

スポンサーサイト

第16回 J2EE勉強会

今日、初めてJ2EE勉強会に参加した。場所は新宿。
この会の存在は、WithoutEJBで知っていて参加してみたいと思っていたがなかなか機会がなかった。WithoutEJBの議事録はアーキテクチャについて研究していたときにGoogleで引っかかったもので、なかなか読み応えがあった。

印象としては、結構マニアックな感じだったが、純粋に技術を追求しているところがなかなかよく、時間は5時間弱だったが、それほど長く感じなかった。最近の技術や概念がいろいろ出てきて内容が濃かった。

今日のお題は、
・Shale
・Maven2
・JaSST06レポート
・Mayaa
で、どれも自分にとって目新しく興味深い内容だった。
最近の個人的な興味の対象はアーキテクチャパターンで、前はその辺のテーマがよく議論されていたようなのだが、今回は特になかった。

Shaleは、俗にStruts2.0と評されるものだが、内容はJSFの実装の一つで、また旧来のStrutsと比べると、Fine Grainedなところが大きな特徴。Fine Grainedとは、従来のAction.executeの一枚岩的なものではなく、init, preprocess, prerender, destoryメソッドが順に呼ばれ、きめ細かい制御が可能になるということ。
まあ、JSFもそれほど広まっていない状況なので、Shaleが広まるとしたらだいぶ後のことらしいので、急いでキャッチアップする必要はなさそう。

Maven2については、プロジェクトの作成から、eclipseへのインポート、ビルド実行までデモを見せてもらった。結構、使いこなせるようになるまで時間がかかるようだ。Antで十分と思っているうちは駄目かな。

JaSST06のレポートも興味深く、ソフトウエアテストについてはいろいろ研究したい。

Mayaaについては、HTMLをベースとしたWebテンプレートエンジンぐらいの知識しかない状態だったので、結構内部の話で、ついていけないところがあった。初歩的な解説をお願いしておけばよかった。私がStrutsタグで問題だと思っていたプログラマとデザイナの作業分担についてはかなり解決できそう。


カスタムタグとORマッピングツール

あまり好きじゃないもの

1 strutsタグ(広義にはカスタムタグも)
2 ORマッピングツール

この二つに共通しているもの、それは中途半端だということ。
なぜかというと、1は所詮HTMLに変換され、2はSQL文に変換される。完全にラップされているならいい。ところがそうじゃない。

HTMLは一番下、ベースだ。ブラウザ上ではHTMLを使って表現する。HTMLの枠から出ることはできない。ということはHTMLを押さえておけば、ブラウザ上のUIでできることはすべて押さえていることになる。

VBであれば、Visual Studioでのコンポーネントのぽとぺたがベースだ。もしVBの画面で気に入らなくてもその中でやるしかない。それが嫌ならもっと低レベルの言語でGUIを組み立てるしかない。通常のUIとしてはたいていはOKである。

中途半端なものは、結局その下を意識しなくてはならなくなる。JavaがOSを意識させないといっても微妙な問題になると、どうしてもOSレベルを知らなくてはならなくなる。とはいえ通常のレベルでは問題ない。

ところが先にあげた1,2は、ほんの少しでも変わったことをしようとすると、すぐさま対応できなくなる。これくらいのことはできるだろうと思っていろいろやってみると、ついにはそれができないことが発覚する。そこで費やされた時間は無駄だ。しかもできない部分は、それらを使わないようにすると、全体的に統一感がなくなってしまう。

そんなことならゴリゴリとHTMLやSQLを組み、自分で必要があれば共通化できる部品を作る。自分で作ったのだから一番よく知っている。チームで作った人間がいればその人に聞けばいい。

よく精通して、使用限界を知っている人がチームにいない限り、中途半端なものは使わない方がいい、と思う。

業務アプリとオブジェクト指向について

何度か、独断的なオブジェクト指向論を述べてきたが、ここで少しまとめておこうと思う。

まず第一に、個人的には、オブジェクト指向は好きだし、構造化分析よりも優れていると思う。それは構造化言語よりも多くのことができるからである。世間で勘違いされているような「飛躍的に」まで生産性が高まるとは思わない。また、オブジェクト指向が難解でマスターするのが難しいとも思わない。

難しいと思われている理由は、一つには旧来の手法から移行することが難しいということがあるが、実際には期待したほど生産性が高まらず、原因はきちんと使いこなしていないからだと思い込んでいるためだと思う。これはオブジェクト指向やデザインパターンを魔法のように勘違いしているためだ。
もしオブジェクト指向言語を使ったにもかかわらず、生産性が低いとしたら、多くの場合、開発者が構造化すらできていない、べた書きソースを書いている場合が多い。

データ中心指向(DOA)と対比すると、オブジェクト指向(OOA)も手続き指向(POA)に対抗して出現したものだが、パラダイム的には、データと手続きがセットになっているため、POAとDOAの中間に属する。

業務アプリケーションを作成する際、DOAもOOAもドメイン分析に時間を費やす。OOAでは処理もセットで考慮する点が異なる。

RDBを使って業務アプリケーションを作成する場合、私はDOAの方がよいと思う。多くの人がOOだと思っているのはOOではないし、純粋にOOで組んだ場合、問題がある。

多くの人がOOだと誤解している場合二つあって、一つはJavaを使っているという理由でOOだと思い込んでいるケースと、最終的な実装ではOOライクだが本質はPOA+DOAになっているケース。レイヤーを分けたり細かくモジュール分割したとしてもOOAとは言えない。

業務アプリがDOAの方がいいと思ういくつか理由を述べる。

1.エンティティクラスに特有の機能は不要
 前に述べたとおりテレビ・プロダクト・クラスにテレビが持つ機能は不要。だからといって構造体を使えというのではない。実際、私が作る場合も、単純なgetter, setter以外のメソッドを追加する。だからオブジェクト指向言語を使う意味はある。ただこのエンティティクラスは、しばしばオブジェクト指向ではアプリケーションドメインの中心的存在であるにもかかわらず、さほど大した役割を果たしていないことがある。
 処理の面が強く出ているエンティティの場合、オブジェクト指向が適切だ。この場合、データモデルで始めるより、クラス図ではじめ、データベースにマッピングしていくというスタイルでいいと思う。ただ業務アプリケーションのデータの場合はこの例にはならない。

2.エンティティと処理を分けることになる
 ドメイン分析でクラス図を使用するが、多くの場合それをそのまま実装に落とし込めない。エンティティと処理(サービス、DAO)は分割することになる。
 1の理由や処理の明確化で、分けた方がきれいになるし、わかりやすい。EJBの初期のころ、EntityBeanにロジックが書かれていたが、煩雑になるため、ロジック層は分離され、EntityBeanはデータアクセスのみに専念し、その間の通信にDTOが使われるようになった。

3.フレームワークで形式が統一される
 レイヤーを分けたり、フレームワークを使うと統一感のためにオブジェクト指向が適用しにくい。

4.SQLで必要なロジックを組める
 これは特に参照系で言えること。検索ロジックはすでにDBMSで実装されており、SQLというシンプルな言語によって表現できる。そのため、ロジックはデータアクセス層におけるSQLという形で表現され、ロジック層は単なるコントローラー層でしかなくなってしまう。EJBでは、更新系にはEntityBeanを使うが、参照系ではSessionBeanからJDBCでSQLを投げるアプローチが実際的だった。
 
 OOAでは、インスタンス単位に処理を行うが、DOAでは、表に対して一括して処理を行う。そのため、一括して処理を行いたいとき、OOAのアプローチは、まどろっこしい感じがする。

5.データベースで一元管理した方がいい
 永続装置へのアクセスを一元管理できるのであればいいが、SQLを使えばどこからでもアクセスできてしまう。オブジェクト上で更新処理を行って、それをデータベースに反映させるというアプローチは、別プロセスからのアクセスとバッティングする問題を発生させやすい。排他制御は高くつき、性能を劣化させる。
 ORマッピングツールを使用しても、性能上の問題からRDBやSQLを意識せざるを得ない場合が多い。

オブジェクト指向DBを使った経験がないために、RDBという限定詞をつけたのだが、おそらく同様のことがあると思う。業務アプリと一括りにするのはよくないし、オブジェクト指向が向いている場合もあると思う。

まあ、結論としては、
1.多くの人がOOと思っているのはOOではない
2.ORマッピングツールよりもSQLが好き
という単純にそれだけのことかな。

Developers Summit感想

今日Developers Summitに参加した。
場所は目黒雅叙園で初めて行ったのだが、ずいぶん和風なところでやるものだ。

時間の都合があって、午前、午後1セッションずつのみ参加。

最初はGeronimoのセッションに参加した。
最近時々耳にしていたので概要を知りたいと思った。Apacheプロジェクトに所属する、J2EEサーバのプロジェクトで、独自の開発というより、オープンソースを自由に組み合わせて使うための枠組みで、つい先月ver1.0がリリースされたばかりだ。
JBossとの違いは、LGPLライセンスとApacheライセンスの違いということ。
全サービスおよびアプリケーションを、MBeanを拡張したGBeanで管理する。
各サービス間をDIを使って疎結合にする
Tomcat, OpenEJB, ActiveMQ, HOWLなどを自由に組み合わせることができるオーダーメイドサーバ。
といったところが特徴的なところ。
cf.
http://geronimo.apache.org/
http://www.wsdeveloper.com/

もうひとつ参加したのは同じくC会場の最後のセッションで、オープンソースについて。
オープンソースの活用の仕方ではなく、オープンソースの開発者によるパネルディスカッションで、どのような状況でオープンソースの開発を聞くことができた。直接、役に立ったわけではないが、背景を聞くことができて面白かった。

S2Hibernateを試す

DIコンテナ+AOPのSeaserのプロジェクトのひとつにS2Hibernateがある。
これは、ORマッピングツールであるHibernateをSeaserに統合して、使いやすくしたものだ。以前、K氏に紹介してもらい、また@ITでもしばしば取り上げられるので試してみたいと思っていた。

自分で行っている家計簿のサンプルプロジェクトの中で利用してみた感想を述べたいと思う。これを試したのは、去年の11月だったが、なかなかブログに書く時間がなくて今ようやく書いてみることに。

このプロジェクト、アプリケーションのアーキテクチャーは、もともと、
プレゼンテーション層にStruts、そしてロジック層があり、データアクセス層にはDbUtilを使っていた。プレゼンテーション層からロジック層の呼び出しは、独自のコンテナでやっていた。個々のFactoryクラスを作るのは無駄だと思っていたし、昔からずっとこのやり方でやっていたので、またDIしなくても共通クラスを継承してもいいんじゃないという感じだった。親クラスの代わりに、メンバーに依存クラス(インターフェース)を持つわけで、それがインターフェースだろうが具象クラスだろうと何らかのものに依存することには変わりないのだから。
なので、DI+AOPを適用したときも、DIの部分では特に有り難味を感じることはなかった。AOPについては、ログやトランザクションで、データアクセス層がかなりすっきりするようになった。

DbUtilは、ROマッピングと言っていいと思う。ORは手動で行う必要がある。DbUtilだけでは不十分なのでひとつWrapperをかませているが。私は業務アプリに関してはDOAの人間なのでORマッピングの必要性は感じないし、これで十分だと思う。もっと小規模であれば、データクラスを作らずにMapで済ませてしまうのでも十分だと思う。

DbUtilを使っているときのOは、単なるDTO(データ転送用オブジェクト:単純なデータ格納クラス)で、ドメインモデルではない。
何が違うのかと言うと、ドメインモデルの場合、クラス図に描かれているような、他クラスとの関連が定義される。例えば、Groupクラスが、Userクラスを持っている場合、
class Group {
  Set<User> users;
  ....
}

class User {
  Group group;
  ....
}
となり、直接関連するオブジェクトへの参照を持つ。これがDTOの場合、
class User {
  String groupid;
}
となって、Groupクラスとの関連を持たない。テーブルのレコードをコピーしてきただけである。こうする場合、例えばUserオブジェクトから、グループ名を引き出したい場合、DTOであれば、あらかじめUserクラスに、
String groupname;
というメンバーを用意しておいて、データベースから値を取ってくる際に、UserテーブルとGroupテーブルをJOINして、グループ名を持ってくる必要がある。
一方、ドメインモデルの場合、その必要がなく、すでに参照はあるので、
user.getGroup().getName();
で持ってくることができる。なので、必要なときになってからGroupオブジェクトを取り出せばいい。DTOの場合、あらかじめDBに問い合わせておかなければいけない。

また、DTOの場合、テーブルのデータをコピーしているので同じインスタンスがメモリ上で重複する可能性がある。複数のユーザ情報を持ってきたとき、そのすべてにグループ名があることになる。ドメインモデルであれば、グループ名はGroupオブジェクトに1つあるだけで、Groupオブジェクトは重複していない。

こういった違いがある。ただこのドメインモデルの考えは理想的にであって、実際にこれをどう実現するのかは難しい。先ほど必要になってからGroupオブジェクトを取り出せばいいと述べたが、これはORマッピングの世界では遅延ローディングと言われているものだが、実際その使用にはいろいろと制限があり、プレゼンテーション層まで引っ張り回すのは推奨されていない。

私はこれでは利便さが失われてしまうと思う。DBのJOINを意識せずにできるのが利点だが、それが最も必要とされる場所で使えないとなると、大した利点ではなくなる。実際、サービス層での遅延ローディングもうまくいかなかった。ここはセッションを引き伸ばせばできたかもしれない。

また、オブジェクトの共有も、データベースにアクセスしているセッション内のみであって、アプリケーション全体ではない。結局、DTOにおけるコピーと大差ない。

むしろ、ドメインオブジェクトをプレゼンテーション層に渡すためのDTOに詰め替える作業が煩雑で、先のグループ名をセットするのに、
userDTO.setGroupName(user.getGroup().getName());
といちいち全部を変換する必要があり、これなら最初からデータベースをJOINして持ってきてセットした方が簡単だった。

再帰的な構造を持ったテーブル(オブジェクト)を扱っていた部分があって、それを画面に表示するときにツリー構造に直す必要があって面倒なロジックを組んでいたのだが、この点に関しては、このドメインモデルによって簡単に構造化できた。しかし、それをDTOに詰め替える作業で結局同じだけの長さのコードが必要になったが。

更新系についても、そう簡単にはいかなかった。createについてはよいが、updateの際に成功した行数を返し、対象がないときにはエラーメッセージを表示するようにしていたので単純なやり方ではうまくいかない。deleteも同じで、また論理削除をするやり方にしていたのでこれまた簡単にはいかない。

こう言うと、必ずそういう作りにしているのが悪いと言われる。所詮こういうツールはシンプルな使い方をより便利にするだけだ。少し変わった要求を持ち込むと途端に対応できなくなる。あるいは対応できるように拡張していくと、ひどくツールが複雑になって学習時間がかなり必要になる。

ORマッピング Caché

少し前に、業務アプリケーションとオブジェクト指向の関係について述べた。
業務アプリケーションにはオブジェクト指向が向かない理由として、1.エンティティクラスに機能は必要ない、2.メモリ中心で実装した場合困難がある、ということだったが、2番目の点についてはオブジェクト指向データベースを使った場合には当てはまらないとの指摘を受け、再度考察し、整理したうえで公開HPに展開しようとしてまとめている。

2の点を挙げたのは、かつてメモリにデータを展開して頓挫したプロジェクトを見たからと、オブジェクトをシリアライズして保存する簡易アプリを作ってみた感想からだった。確かに、自前で作る場合は、データ中心、かつ、マルチアクセスに対応するのは困難だ。しかし、オブジェクト指向データベースでは、これらに対する対応がなされている。
そのため、オブジェクト指向データベースについて検討する必要があると思っていた。データベース=RDBという考えを改めないといけない。

ただ、第1の主張については変わりない。基本的にエンティティクラスには、機能は必要ない。例えば販売管理システムで、商品クラスがあり、そのサブクラスとしてテレビクラスがあったとして、その属性にはサイズや方式等が定義されるだろうが、スイッチを入れる、表示をする、等のテレビらしい機能は全く不要だ。属性は現実を反映するが、機能は現実を反映しない。

もちろんエンティティ全般には共通して、検索・生成・更新・削除等の機能が必要だろう。だから抽象化したエンティティに対してオブジェクト指向を使うのは問題ない。.NETでは、DataSourceをGUI上でフォームに貼り付けるなどをして、オブジェクト指向らしくプログラミングをすることができる。しかしそれはエンティティ全般に対してであって、それは個々のエンティティに特有のものではない。


ところで、最近、参加しているDB研究会でCachéを取り上げている。これを機にCachéについてしっかり調べておこうと思う。Oracleより性能がいいとの話があって、一年前にInterSystemsの無料の講習にも参加したのだが、その後は結局時間もなく、書籍も読み解くのが面倒な感じに思えたので特にそれ以上追求することはなかった。

今日、DBにどのようにアクセスするかの話になった。実際にプロジェクトで携わった人も参加していて、ほとんどSQLもトランザクションも意識することはないとのことだった。SQLレスというのは、オブジェクト派にとってうれしいことだろう。

Caché言語でなくてもJavaでもCachéにオブジェクト的にアクセスできる。 Javaバインディングにより、Java アプリケーションは Caché サーバ上のオブジェクトと相互運用できるという。
サンプルを見たのだが、ORマッピングツールっぽいやり方だ。先日、@ITでもHibernateとの比較が出ていたが、ここでは大きな差はない。

一番知りたいのは、複雑な条件句、副問い合わせ、多くのテーブル結合、さらにunionを使ったSQL文など、複雑な形態のSQL文だ。こういうのをどうやって実現するのか。

更新文ならば、それに比べてシンプルだ。条件句を複雑にする場合除いて、大体定型化できるので、ORマッピングツールではSQLレスを実現できる。この程度であれば、普通のプログラマでもマッピングモジュールを作るのは難しくはない。正直言って、SQL文を書いたところで大して汚くならないので、個人的にはあまり有り難味はない。

ORマッピングツールでは検索は結局SQLみたいなロジックが登場する。今日seo氏から次世代.NETの解説があったが、そこでもLINQ、SQLを言語に落とし込む記法が紹介されていた。

DOA派が複雑なSQLを書くのはひとえにSQL発行の回数を減らしたいからだ。ただDB上でストアドプロシージャとして記述すればわかりやすいロジックで書けるだろうと思う。それでも一回のSQLで欲しい結果が持ってこれるように書くのは、パズルを解いているような感じの醍醐味があるのだが。

おそらくCachéは、ロジックをDB上で実行するので、つまりストアドと同じ感覚になるので、複雑なSQLはシンプルな検索メソッドに分解されるのだろうと思う。
ここはこれから調査が必要。

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。