サイオースラボ
サイオステクノロジーはグルージェントの未来技術に期待し子会社化
サイオースラボみたいな感じかしら。どこかで聞いたような語感ですね。(笑)
developerWorks:WASにTeedaをデプロイする
Seasar2 と Teeda を利用した Web アプリケーションを WebSphere Application Server にデプロイする
developerWorksにTeedaをWASにデプロイするための記事が出てます。今後は、定期的にdeveloperWorksに記事を掲載していく予定です。こんなのを書いてほしいとか要望があれば、遠慮なくどうぞ。書くのは私じゃないかもしれないけど(笑)。
ドメインモデル
「抽象クラスを継承してエンティティ特有のビジネスロジックを実装する」ってことは、そのエンティティは貧血でないドメインオブジェクトってことでしょうか。
SAStrutsの機能リファレンスでは「複数のアクションから共通に使われるような機能は、サービスクラスで実装すると良いでしょう」との記述もありますが、サービスとエンティティに実装するロジックの切り分けは、やはり粒度に応じてってことになるのでしょうか。
SAStrutsでは、エンティティ特有のビジネスロジックは、そのエンティティに持たせることを推奨しています。ということは貧血症(?)ではないオブジェクトだということです。しかし、肥満症(?)なわけではありません。SAStrutsのドキュメントにはこうかかれています。
ビジネスロジックは、エンティティに 定義します。ビジネスロジックと間違えやすいのが、データアクセスのロジックと、 エンティティの関連をたどる(部署のエンティティから関連先の従業員のエンティティをみにいくこと) ような複数種類(部署と従業員)のエンティティにまたがるようなロジックです。
複数種類(部署と従業員)のエンティティにまたがるようなロジックは、制御ロジックとして、アクションやサービスに持たせます。
複数種類のエンティティにまたがるようなロジックをエンティティ持たせようとすると、どのエンティティに持たせるのかに正解はなく、人によってばらつきます。しかし、制御ロジックと捉えて、アクションやサービスの持たせれば、迷うことはありません。
エンティティは、粒度の小さいオブジェクトなので、そのエンティティに閉じているメソッドのみを持つのが良いと思っています。
前といってることが違うジャンって。いいんです。道具がかわれば、それをできるだけ生かした使い方をすべきだから。
HibernateとS2DaoとS2JDBCの考え方
HibernateはEntityを中心に考えます。つまり、Javaを中心に考えるということですね。エンティティモデルとERモデルは、一致する必要はなく、それぞれでモデリングして、Hibernateが間をつなぎます。
メリットは、エンティティの設計がデータベースに引きずられることなく、そのドメインを正確に表したものになること。ほとんどのSQLは自動生成するので、SQLを書かなくてもすむこと。
デメリットは、エンティティとデータベースを個別にモデリングする必要があり、二つのモデル間でインピーダンスミスマッチが起きること。また、自動生成されたSQLの効率が悪くなるリスクがあります。継承や遅延ロードによってパフォーマンスが落ちることもあります。
フレームワークががんばっているので、機能が豊富なのですが、その分オーバヘッドがあり、学習コストがかかります。
S2DaoはSQLを中心に考えます。とはいえ、すべてのSQLを開発者が書くのは効率が悪いので、挿入、更新、削除は、S2DaoがSQLを自動生成しますが、検索は、開発者に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が良いと思います。
