IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
はじめに CJ2EEのDataAccessObjectパターンは、企業向けシステム開発で利用される非常に優れたデザインパターンです。これを利用することにより、柔軟なシステムを構築することが可能となります。有名なパターンなので、多くの方はこのパターンを使った設計/開発に携わった経験があるのではないかと思います。 しかし、DataAccessObjectパターンを使った開発は多くのクラスやインターフェイスを定義する必要があります。これは、DataAccessObjectパターンがAbstructFactoryパターンをベースとしているためです。クラスやインターフェイスの数が増えると開発コストだけでなく管理コストも増大し、開発規模が大きくなるほど影響が大きくなります。 本稿では、こうしたDataAccessObjectパターンのデメリットを回避するためのパターンを紹介します。対象読者企業システム
Java, Wicket いつか誰かがやると思ってましたが、ついにWicketのGoogle Guiceサポートが開発されたようです。Click Frameworkと並んで一番ホットなJavaウェブフレームワークであるWicketと、GoogleのDependency InjectionフレームワークGuiceがついに統合できるわけです。 Wicketには早くにSpring拡張機能が追加されていましたし、国内ではよういちろうさんによるS2WicketでSeasar 2もサポートされています。そこにGuiceが加わる。 Google GuiceはDIコンテナとしては異色の存在です。そのポリシーには「型安全性重視」とか「anti-static」とか書いてますし、あるいはXMLではなくてJavaコードでインターフェースと実装クラスを結びつけるというやり方を見ても、とてもJava寄り。最初にその発
Wicket-Guiceが出来ましたね。 まあ、詳しくは矢野さんの記事読んでください。 ここのまとめでも書かれているように、GuiceはWicketのようにJavaの利点を最大限に活用したDIコンテナなので、Wicketとの相性はとてもいいはずです。 ってことで、標準ガチガチ準拠のWebアプリを作成しなければいけない場合以外は、もう、Wicket-Guiceで僕の中では確定です。 言語がJavaである場合は、ですが(笑) で、こうなると、パーシステンス層をどうしましょ?ってことになりますよね。 S2Wicket-Seasar2ならばS2Daoで確定でいいし、Wicket-SpringならSpringとの連携がしやすいもの(例えばHibernate)でいいでしょうし、Wicket-javaeeならJPA準拠のORMならなんでもいいでしょう。 しかし、せっかくWicketとGuiceというX
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く