Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2008-02-01

developerWorks:WASにTeedaをデプロイする

Seasar2Teeda を利用した Web アプリケーションWebSphere Application Server にデプロイする

Seasar2: 第1回 WebSphere Application Server へ Web アプリケーションをデプロイする

developerWorksTeedaをWASにデプロイするための記事が出てます。今後は、定期的にdeveloperWorksに記事を掲載していく予定です。こんなのを書いてほしいとか要望があれば、遠慮なくどうぞ。書くのは私じゃないかもしれないけど(笑)。

ドメインモデル

「抽象クラス継承してエンティティ特有のビジネスロジックを実装する」ってことは、そのエンティティは貧血でないドメインオブジェクトってことでしょうか。

SAStrutsの機能リファレンスでは「複数のアクションから共通に使われるような機能は、サービスクラスで実装すると良いでしょう」との記述もありますが、サービスとエンティティに実装するロジックの切り分けは、やはり粒度に応じてってことになるのでしょうか。

Tomatoさんのコメント

SAStrutsでは、エンティティ特有のビジネスロジックは、そのエンティティに持たせることを推奨しています。ということは貧血症(?)ではないオブジェクトだということです。しかし、肥満症(?)なわけではありません。SAStrutsドキュメントにはこうかかれています。

ビジネスロジックは、エンティティに 定義します。ビジネスロジックと間違えやすいのが、データアクセスロジックと、 エンティティの関連をたどる(部署のエンティティから関連先の従業員のエンティティをみにいくこと) ような複数種類(部署と従業員)のエンティティにまたがるようなロジックです。

Super Agile Struts - Feature Reference

複数種類(部署と従業員)のエンティティにまたがるようなロジックは、制御ロジックとして、アクションサービスに持たせます。

複数種類のエンティティにまたがるようなロジックをエンティティ持たせようとすると、どのエンティティに持たせるのかに正解はなく、人によってばらつきます。しかし、制御ロジックと捉えて、アクションサービスの持たせれば、迷うことはありません。

エンティティは、粒度の小さいオブジェクトなので、そのエンティティに閉じているメソッドのみを持つのが良いと思っています。

前といってることが違うジャンって。いいんです。道具がかわれば、それをできるだけ生かした使い方をすべきだから。

HibernateとS2DaoとS2JDBCの考え方

HibernateはEntityを中心に考えます。つまり、Javaを中心に考えるということですね。エンティティモデルERモデルは、一致する必要はなく、それぞれでモデリングして、Hibernateが間をつなぎます。

メリットは、エンティティの設計がデータベースに引きずられることなく、そのドメインを正確に表したものになること。ほとんどのSQL自動生成するので、SQLを書かなくてもすむこと。

デメリットは、エンティティとデータベースを個別にモデリングする必要があり、二つのモデル間でインピーダンスミスマッチが起きること。また、自動生成されたSQLの効率が悪くなるリスクがあります。継承や遅延ロードによってパフォーマンスが落ちることもあります。

フレームワークががんばっているので、機能が豊富なのですが、その分オーバヘッドがあり、学習コストがかかります。

S2DaoSQLを中心に考えます。とはいえ、すべてのSQL開発者が書くのは効率が悪いので、挿入、更新、削除は、S2DaoSQL自動生成しますが、検索は、開発者SQLを書いてもらいます。

メリットは、SQLを自前で制御できるので、トラぶりにくいこと。機能が少ないので、簡単に覚えられること。

デメリットは、SQLを書くのが面倒なことです。また、検索の結果セットごとにDTOを作らなければいけないので、DTOが増える傾向があります。

S2JDBCは、エンティティ(Java)とテーブル(データベース)は、同一のモデルだとみなしています。また、複雑なSQL以外は、すべて自動生成します。Hibernateから継承や遅延ロードなど、有効な場合もあるがトラぶりやすい機能を削除したのがS2JDBCです。

複雑なSQLは、S2Daoと同様に開発者が記述できます。

メリットは、SQLをほとんど書かなくてもいいこと。エンティティとテーブルが同じモデルなので、モデリングが一度ですみ、インピーダンスミスマッチがおきないこと。エンティティとテーブルが同じモデルという前提なので、Hibernateと比べてマッピング仕様シンプルで、学習コストが低いこと。トラぶりやすい機能が削除されているので、トラぶりにくいこと。複雑なSQLでも問題なく対応できること。

デメリットは、エンティティの設計が、テーブルに引きずられ、完全にドメインをあらわしたものにならないこと。たとえば、開始と終了の値を範囲というオブジェクトマッピングしたりすることはできなくなります。

エンティティは、テーブルに引きずられることなく、モデリングしたいということなら、Hibernateがいいでしょう。

エンティティとテーブルは同一構造でいいと考えられるなら、S2JDBCが最も使いやすいでしょう。ちなみに、Railsもエンティティとテーブルは同一だとみなしています。エンティティとテーブルを分けてモデリングする方式は、二度手間だし、苦労の割には、メリットが少ないので、今後はエンティティとテーブルを同一構造とみなす考えが主流になると思っています。納期短縮、工数削減プレッシャーは今後ますます強くなるでしょうから。

SQLを書くのが好きな人は、S2Daoが向いてますが、実はS2JDBCでも同じことができます。Daoパターンがすきな人はS2Dao、そうでなければ、S2JDBCが良いでしょう。

Webフレームワークとの組みあわせでいくと、Teeda Extensionは、S2Dao(DTO)と相性が良いように設計されているので、Teedaを使う場合は、S2Daoが良いと思います。

sugimotokazuyasugimotokazuya 2008/02/01 17:30 HibernateとS2Dao(とS2JDBC)の比較というか考え方の違いというか、そのあたりの記事を希望します。

wataruwataru 2008/02/01 19:19 どちらかというとスクラッチ開発でRDBを単なるストレージと考えている傾向がるRails(ActiveRecord)を対象にだして今後主流になると言うのは飛躍し過ぎではないでしょうか?
海外ではエンタプライズ系はDDDやREAなどドメインモデルパターンを有効に活用する流れの方が強かったイメージがあります。
Grailがドメインモデル中心なのもその表れかと、S2JDBCが便利な事には違いありませんが:-)

higayasuohigayasuo 2008/02/01 19:58 ドメインモデルとERモデルを別個にモデリングするのは、効率が悪いし、手間の割りにはメリットが少ないので、同一だとみなすほうが主流になると思いますよ。
工数圧縮、納期短縮のプレッシャーは今後より強くなりますから。
Railsの話は、ミスリードにつながるかもしれないので、削除しました。

yuum3yuum3 2008/02/01 21:19 ちゃんと読めば判りますが、「エンティティとテーブルを分けてモデリングする方式は、二度手間だし、苦労の割には、メリットが少ないので、今後はこの考えが主流になると思っています。」の
”この考え” が ”エンティティとテーブルを分けてモデリングする方式” を表してるいるようにも読めてしまいます。

higayasuohigayasuo 2008/02/01 21:30 > yuum3さん
ありがとうございます。修正しました。

sugimotokazuyasugimotokazuya 2008/02/01 23:06 ひがさん、ありがとうございます。
わかりやすくフレームワーク選定の参考になりました。
あとDaoパターンでしばらくやってきたのですが、S2JDBCやLINQだと、テーブル構造に変更があった場合に保守のしやすさはどうなんだろうという疑問を持っていました。
このあたりは実際に自分でコードを書いてみて、確認してみようと思います。

TomatoTomato 2008/02/01 23:59 ありがとうございます。とてもよくわかりました。

dmdm 2008/02/02 13:25 > 工数圧縮、納期短縮のプレッシャー
こちらの話とレガシーDBが存在するかは別問題ですよね。
多くのケースでは新規でDB設計できるケースはまれで、
既存資産を流用して開発を進める事になると思いますが
そこでドメインモデルとERモデルを同一視して表現するのは、
かなり厳しいと思います。

単純にテーブルバインディングしたエンティティを持って
ドメインモデルと表現しているわけではないですよね?
開発者の好き嫌いだけでなく、現場も制約も念頭において
主流になるか判断された方が良いかと思います。

一方で新規案件を前提として考えると面白い考えだと
思いますが、ドメインモデルをERモデルと同一視するのは
流石にERモデルが重くなりすぎるかと…

Connection: close