ひがやすを技術ブログ

電通国際情報サービスのプログラマ

ThreadSafe問題

S2Struts

S2Strutsの外からS2Container.register()を呼ばれたときは、どうしようもないですが、それは、現実的にないから良いんじゃないかと思います。それを避けるためにgetCompoentDef()系まで、synchronizedにはしません。パフォーマンスの代償が大きいから。
Pluginで処理するのが、もっとも現実的な気がします。

ローカルDTO

くーす

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?LocalDTO
DTOには、主に3つの目的があるように思います。

  1. リモート呼び出しの回数を抑えるための大きなデータの入れ物
  2. オブジェクト間(層間)でデータをやり取りするための入れ物
  3. プレゼンテーション層のモデル

分散アプリケーションは、ほとんど必要ないというのが最近の流れなので、1の目的で使われることは少ないでしょう。
2と3はセットで考える必要があります。
2の問題点は、ドメインオブジェクトとDTOの相互変換をするのはコストがかかるという点です。これは、私も同意しますが、結論を出す前に3を考えてみましょう。
プレゼンテーション層のモデルとしてDTOを使うというのが、DTOの最も適した使い方だと思います。
Fowlerはプレゼンテーション層で必要とされる構造とドメインオブジェクトの間にミスマッチがあるときだけ、DTOを使えといっていますが、たいていの場合(よほど単純な画面でない限り)、ミスマッチはあるものです。
また、プレゼンテーション層でドメインモデルの構造を理解して入出力のロジックを組み込むのも良くありません。プレゼンテーション層は、プレゼンテーションに徹し、ドメインの知識は持つべきではないからです。プレゼンテーション層は、テストしにくいので、できる限り単純にしたほうが良いという考え方もあるでしょう。
そう考えていくと、プレゼンテーション層のモデルとして、DTOを使うというのは、理に適ったことだということが分かります。
3が必要だということをふまえて2に戻りましょう。
オブジェクト間(層間)でデータをやり取りするためにDTOを使うこと自体は問題ありません。問題なのは、ドメインオブジェクトとDTOの相互変換のコストです。このコストはばかになりません。
そこで私が主張するのは、RDBMS<->ドメインオブジェクト<->DTOではなく、直接、RDBMS<->DTOしてしまえというものです。これなら、ドメインオブジェクトとDTOの相互変換のコストはかかりません。業務ロジックは、Statelessな業務ロジック層(サービス層)にもたせます。
DTOをこのように使うときに重要なポイントがあります。DTOはエンティティ(ドメインオブジェクト)を継承するということです。DTOの構造をプレゼンテーション層の都合のみで考えると、同じような業務ロジックが分散する危険があります。
これは、どのようなドメインにもいえます。再利用性の高いロジックも業務ロジック層におけるからです。

S2.1.5 S2Flex1.0.4リリース

Seasar2

S2.1.5
リリースメモ

  • ユーティリティクラス(LocaleUtil,ResourceBundleUtil)の追加

修正点

  • S2StrutsV1.0.12にあわせてS2Container.registerの余分なsynchronized指定を削除

S2FlexV1.0.4
リリースメモ

  • Javaのプロパティファイルを使ってFlexで多言語に対応できるようにしました。

S2FlexExampleV1.0.5
リリースメモ

  • ValidatorのエラーメッセージをJavaのプロパティファイルで多言語対応するためのサンプルを追加しました。

S2Flexは、MapやListを使ったネストしたJavaのオブジェクトをFlexとやり取りする良いサンプルにもなっていると思います。Flexでのインターフェースの使い方も。
Flexで、"{0}は必須です"のようなJavaのMessageFormat形式のメッセージを解析して組み立てるのは、かなり困難(もちろんやればできるけど)です。
そのため、Javaの方で、メッセージを解析してメッセージを処理するためのオブジェクトを組み立て、それをFlexに送りこみ、Flexの方では単純な処理だけをする方式になっています。