10章 Persistence
透過的な永続性をより尊重すべしと言う主張は、今までRodの主張としても余り見なかったのでちょっと斬新。
データアクセス層のライブラリをInHouse?で実装するのってどう？
InHouse?ソリューションを使う事が多い人は、会場20〜25人中、5人位。
InHouse?ソリューションを使うと、
- 開発を行う上での責任問題を明確にする事が出来る
- RDBの能力を極限まで引き出す事が出来る
全体として工数の大きいプロジェクトで、その一部として力技を使うのは、それはそれでアリかも…。
キャッシュについて
- キャッシュのテクノロジは自前で実装せず既に存在するライブラリを使用する方が良い。
- キャッシュは、機能として複雑かつ難しい、但し、特許の問題が発生する位、研究されている分野ではある。
- キャッシュをInHouse?で作る時には、RDBMSを作る位の気概が必要になる…かも。
cf.
R/Oマッピングについて
EntityBean?には特に大きい問題としてN+1 Finder問題があった。
CMPに関してはEJB2.0で改善されたが、BMPを利用する場合は潜在的に問題は残っている。
iBATIS
- 厳密に考えると、SQLにnullをバインドする際には、型を設定しなければならないがiBATISにはそのAPIが無い為問題があるかもしれない。
但し、PostgreSQL8以外のRDBでは型の指定はnullならVARCHARで設定すれば、何とかなる。
- SQLを外だしにして、簡単に扱えると言う意味では魅力的なプロダクトだった。
JDO
- 条件や変数の部分を文字列として記述すると、コンパイルしてオブジェクトを取り出せる所は、ちょっと興味深い。
- DBから取り出したオブジェクトが実装するアクセッサをコントロールする事で、より強力に情報隠蔽する事が出来るのは魅力的。
- JDOのStateManagement?において、データストアからオブジェクトを取り出し、例えばWeb層の様なクライアントに返す際には、
明示的にAsociate(関連？)を切断(makeTransientメソッドの呼出)しなければ、クライアント層でアクセスしようとした時に例外が発生してしまう。
これは、JDOを利用する上で最初に躓く点かも…。
- JDOは、DBからデータを取り出した後、もしくはクライアント層からの入力を受け付けた後に、
それぞれ環境からオブジェクトを切り離したり、接続し直す為にオブジェクトをコピーしたりしなければならないのは、問題。
Hibernateは、この点JDOよりも優れている。
ちなみに、EJB3ではセッション管理とトランザクション管理が同期している為、暗黙的にこれらの処理が行われるので、JDOの様な問題は無い。
EJB3にはdetach系メソッドがある。
Hibernate
- スナップショットと、入力パラメータとなるオブジェクトが更新されているかチェックするような処理をしている。
- 膨大な量のオブジェクトを取り出して、一部のみ更新するような場合には、パフォーマンスが悪そう…。
- Hibernate3からは、フィールドレベルのLazyLoading?が出来る様になるらしい。
- JDBCではSELECTしてくるカラムの量を減らす事でパフォーマンスが大幅に改善する可能性があるので、選択肢の1つとしては良いかも…。
- HibernateにはVersionNo?及びTimestampによる楽観的排他制御がある。
LazyLoading?について
- OpenSessionInViewを利用する際には、JTA的なトランザクションを、画面表示処理以前でコミットしてしまうのが良いかもしれない。
よってセッションとトランザクションの長さが同じにならない。
- JOIN Fetchを使い画面に表示する為に必要なオブジェクトを全てメモリ上に展開してしまう方が、仕組み上単純になりかつパフォーマンス的にも良い。
- クライアントして複数のプラットフォームを前提とする時には、良いかもしれない。
- 例えば、通常のブラウザと携帯電話等、表示項目数に違いがある時等。
DAO
- ビジネスロジックとパースタンスロジックを切り離す事によるメリットは大きい。
- DAOはポータビリティを求めるべきではない。
- それは、O/Rマッピングツールの実装次第で、DAOのインターフェースが変わる可能性が高い。
例えば、透過的な永続性を実現しているツールを使うか否かで、updateの様なメソッドが必要になるか否かが変わってしまう。
- 再利用性と生産性をトレードオフし、状況に応じてDAOをリソースとして切り出すかどうかを、判断する方が良い。
- 但し、透過的な永続性をサポートしないテクノロジを使ってデータストアにアクセスする際には、DAOを作成するべき。
- それなりに多い人数で行うプロジェクトでは、どんなリソースにどんな処理があるか簡単に分る方が良い。
つまり、業務ロジックを実装するクラスがほぼ空になってしまうとしても、DAOを作る方が良い。
- 逆に、小人数で行うプロジェクトでは、最初簡易的に作り、状況に合わせてDAOをリソースとして切出すようにした方が、それはそれで良い事もある。
- メンテナンス性を維持するのも現実のプロジェクトでは、より低コストで行う事が出来る。
- 変更が伝播しずらくなる様にDelegateInterceptor?と言う選択肢もあるが、
現実的にはAOPをプロジェクトの参加人員の全ての人に理解してもらうのは厳しい為、簡単なクラスを作成させてしまった方が、マネジメント的に楽。
データアクセス時に発生する例外クラスに関する考え方について
Springでは、利用するテクノロジに関わらず、発生した例外の論理的な意味付けにあわせて細かく例外クラスが定義されているが、
S2では、〜Exceptionと言う検査例外に対して、単に〜RuntimeException?の様な非チェック例外クラスにしてしまっているのみ。
何故なら、基本的には、利用するテクノロジが送出する例外に対する処理はアスペクトで一元処理してしまえる可能性が高い為。
SpringにおけるO/Rマッピングフレームワークのサポート
JDBCTemplate,iBATISTemplate
- Springでは殆どのO/RMに対して、Templateクラスがある。
- プロジェクトによって、HibernateとJDBCTemplateを使い分けるのが良いかも？
"RDBMS Operation" Objects
JDBCTemplateよりも高度に抽象化されたAPI。JDOのコーディングスタイルを模倣して実装する事が出来る。
只、余り利用するメリットは少ない。
JDOInterceptor
S2とちょっと似ているかもしれない。何故か、JDOだけInterceptorが用意されている。
PersistantManager?をcloseする必要が無い。
サマリ
Springでは、Hibernateを使うのが一番簡単であろう。
透過的な永続性の重要性をRodは特に強く主張しているように見受けられるが何故か？
- 真のオブジェクト指向？を実現する為には、透過的なオブジェクト指向が必要？
他の章よりも柔軟な記述が見受けられるのは、SpringのORMパッケージはJuergenが実装しているので、本の内容も実はJuergenの考えかもしれない…。
11章 RMI
RMIはファイアーウォールとの親和性が、ちょっと低いかも…。
C/C++との接続で使用するケースもある。但し、より良いそれに対する代替案としてCORBAがある。
CAUCHO、Resinって何て読むのか？
→一応、その場では、「カウチョ」、「レジン」で落ち着く。
Ajax,Curlとか、これからのクライアントからサーバサイドを呼び出す為の仕組み、仕掛けとしてBurlapと言うのは悪く無いかもしれない。
クライアントが何であれ透過的にサーバサイドは実装出来る可能性がある。(ひがさん談)
cf.
HTTP経由でリモート呼出について
- HTTP経由でリモート呼出を実現する際には、セキュリティ上のリスクがある。
- 一般の人がアクセス可能な訳では無いが、システムに対して理解のある人間がハッキング出来る可能性がある。
- Flexはダウンロードしたサーバとしか通信しないような仕様になっている為、比較的セキュリティ上のリスクが低い。
- FlashRemoting?は、単にサーバを公開するとセキュリティ上のリスクが高い。
エンドポイントでAspectを利用し、クライアントサイドにユニークなトークンを送り、それをクライアントとやりとりするのがリーズナブルなやり方。
12章 Web Tier
SpringのBean定義と、S2の.diconの違いについて
S2では.diconファイルでは、各XMLが1つのコンテナになっており、子供を指定するようになっている様に、階層構造を作る事が出来る。
Springでは、ファイルを物理的に分割する事が出来るが、実行時には単にそれらがマージされた状態になる為、全てのBean定義がフラットな状態になる。
但し、AbstractBeanFactory?のコンストラクタ(interface定義としては、HierarchicalBeanFactory?)には、
親となるBeanFactory?を指定する事が出来るようになっているので、XML間で継承階層を作る事が出来る。
これによって、親となるXMLでの定義を子となるXMLでオーバライドする事が出来るようになる。
ヨタ話
- RodがEJBのワーキンググループに入らないのは、RodがEJBをとても嫌っているから…らしい。
- EJB3の発表によってWithoutEJBの内容も結構柔らかく変わったらしい…。
- EJB3のEntityBean?は、現状かなり簡素化されている。
- EJB3の仕様は、最初はある程度簡素な仕様にして、世の中からフィードバックを受けるような方向にある…らしい。
- EJB3には、Hibernateの仕様が多く含まれているように世間は認識しているかもしれないが、
TopLink?のアーキテクトもワーキンググループに居る為、OracleがTopLink?を内部処理として利用する事が出来る位、TopLink?の様な仕様も含まれている。
- TapestryのHoward Lewis Shipは、JSFをとても嫌っている…らしい。
- ユーザの操作がに一定のフローが無いTSSの様なサイトを構築する際には、Tapestryの方が良いかもしれない。
- JSFはコンポーネントツリーをHttpSession?の内容として保持している為、ユーザのオペレーションが分散し易いTSSの様なサイトには向かないかもしれない。
- Tapestryは、HTMLとしてコンポーネントツリーを出力してしまっている為、その問題が少ない。但し、そのモデルを理解するのはちょっと大変かも…。
- 時期のStrutsでは、JSFを実装する事はせず、JSFの拡張点を拡張する事で実現する予定らしい。
特に、commons-chainを中心にJSFのライフサイクル中にある処理を実現する事で、現状のStrutsが抱える実装上の問題を解決するらしい。
例えば、RequestProcesser?。複数の機能をMixIn?するのが非常に難しい、もしくは実装上のトリックが必要になる。
cf.
