「SAStrutsでアプリの設定はどう書く」の続き <component class="java.io.File" name="tmpDir"> <arg>"/tmp"</arg> </component> ognlでシステムプロパティを取り出せるので、例えばTomcatのcatalina.homeを指定出来る <component class="java.io.File" name="tmpDir"> <arg>@java.lang.System@getProperty("catalina.home")</arg> <arg>"tmp"</arg> </component> 以下と同じ File tmpDir = new File(System.getProperty("catalina.home"), "tmp"); Webアプリケーションのディレクトリを指定 <component c
例えばファイル出力先のディレクトリパスなど、アプリケーションの設定をどう書くべきか。propertiesファイルに書いて読み込めばいいと思ったが、そんな必要もなさそう。 コンテナに登録するコンポーネントは、インターフェースを実装したクラスである必要はないのだから、設定値をdiconに書いてコンポーネントとして登録し、Seasar 2.4から追加されたBindingアノテーションを使ってサービスやアクションのコンポーネントにセットしてしまうのが楽そうです。 <component class="java.lang.String" name="hoge"> <arg>"ほげほげ〜"</arg> </component> というのをどこかのdicon、例えばconfig.diconに書いてapp.diconでincludeするなどしてStringをコンポーネントとして登録。そして、その設定値を利用
Java でも比較的先進的な考えを持つフレームワークがたくさんあります。そして、先進的なフレームワークは作者でさえ、流行っている、たくさん利用されていると錯覚する場合があります。利用者となるプロジェクトには大抵、新しいことが好きな先進的な人がいて、アーキテクチャを決めてしまいます。そういう人はよくネットなどで情報を発信します。また先進的であれば、記事や書籍でこぞって取り上げられ（もちろん中の人の努力もあります）、流行ってるように見えてしまいます。実際には出来れば新しいことには手をつけたくない人のほうが圧倒的に多いにも関わらず。 どこかの掲示板で、DIは疎結合のためにあるとか、そのためにインターフェースと実装を分離するんだとか、再コンパイルせずに、設定ファイルの変更のみで実装を変更できるんだとか、書いている人を見て、懐かしく思いました。 こんないいもの(たとえばDI)を理解できないのは、理解
最近また Seasar で悩みまくってる今日この頃。 というわけで、今日はタイトルのような内容で悩みました。 原因はいまだわからず・・・。 HttpServletRequest のヘッダからある値を取得して、それを利用してゴニョゴニョする、みたいなインターセプタを2つ作る必要が出てきたので、下記のようなものを作りました。 Page クラスにかます ForPageInterceptor と、 S2Dao を利用する Dao クラスにかます ForDaoInterceptor みたいなインターセプタです。 ちなみに ForDaoInterceptor は、HttpServletRequest のある特定の値を引っ張って、INSERT および UPDATE の際に Entity の特定のフィールドに値をセットする、みたいなことを行います。 public class ForPageIntercep
と同僚が質問してきた。 独自Interceptorを作成し、app_aop.diconにコンポーネントを追加したが、instance属性を指定しなかったため、singletonとしてTomcat起動時に独自Interceptorが生成される。しかしながら、requestは当然リクエスト時に作成されるため、独自Interceptor生成時点ではrequestインスタンスは存在しないため、DIされない。 そのため、instance属性をrequestと指定するように依頼した。そうするとhotdeploy環境ではDIされることが確認できた。 しかし、InterceptorからLogicをDIする設定にしているのだが、DIされない。app_aop.diconにコンポーネントを追加したため、SMART Deployではなくなっていた。InterceptorCreatorにより、interceptor
アプリケーションの設定値、例えばファイルアップロードで使う一時領域のパスやシステムで使う定数などをpropertiesファイルで持たせようかと思ったけど、diconファイルに登録する便利な方法があったので。 SAStrutsのソースディレクトリ（src/main/resource）にconfig.diconファイルを生成し、設定値を管理する。例えば下記のようなString型の名前がsampleで値が”サンプル”を作ってみます。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container 2.4//EN" "http://www.seasar.org/dtd/components24.dtd"> <!-- サンプル --> <component class="ja
This document provides an overview of dependency injection and describes how to build a simple dependency injection container in PHP 5.3 using anonymous functions (lambdas). It discusses how the container can be used to manage parameters, describe object creation through lambdas, handle object scoping, and provide a unified interface. The container allows decoupling object dependencies and makes c
DI の自由度は諸刃の剣 近ごろ、「実プロジェクトでDIコンテナ（注1）を導入している」という話をちらほら耳にするようになりました。それと同時に、「DIコンテナを使ったプロジェクトが大変なことになっている」という話も耳にするようになりました。DIの魅力を十分に享受して低コスト、高品質を実現しているプロジェクトがある一方で「DIを導入してみたのはいいのだけれど、DIの設定ファイルが大きくなりすぎて管理しきれない」「DIを使っているのに、テスタビリティが全然向上していない」など苦労しているプロジェクトもあるようです。この差はいったいどこから来るのでしょうか。 DIは、EJBなどと比べると比較的取っ付きやすい技術ではありますが、ほかの技術同様、誤った使い方では十分に力を発揮できません。DIコンテナは非常に単純明快な技術ではありますが、そのシンプルさ故に自由度が高くさまざまな使い方ができます。その
The document discusses dependency injection (DI) in PHP using the BEAR framework. It shows how DI allows classes to declare dependencies without knowing how to instantiate them. The User class declares a dependency on a Storage interface without knowing the concrete class. The document provides various examples of injecting dependencies into classes through the constructor, setter methods, and a g
“DI”や“AOP”というキーワードを耳にしたことがあるだろうか。これらのテクノロジは、.NET技術者にはまだまだ普及していないのが現状だが、Java開発での長年の利用結果から見ても開発生産性を飛躍的に高めてくれるテクノロジであることは間違いなく、.NET開発でも必ず役立つものであり、むしろ使わない手はない。従って、できるだけ多くの.NET開発者にこれらのテクノロジの良さを知っていただき、有効に活用していただきたいと筆者は考えている。 そこで本稿では2回にわたり、前編でDIを、後編でAOPを紹介していきたいと思う。本稿を通して.NET開発におけるDIとAOPの有効性と可能性を感じ取っていただければ幸いである。 ■1. DIとAOPを理解するためのサンプルの作成 DI（Dependency Injection。依存注入）とAOP（Aspect-Oriented Programming。アスペ
Javaの世界では、POJOというものが流行している。Plan Old Java Objectの略で、Martin Fowler氏らの造語だ。シンプルで、依存性をなくしたオブジェクトのことをさす。しかし、このPOJOというものをどう捉えるべきか、まだまだはっきりしていないのではないかと感じる。ここでも、僕なりの説明を試みるわけだが、正解といえるかは分からない。ただ、方向性としては間違っていないと思っている。 POJOとは まず、POJOを、もう少し詳しく定義するなら、「自分がするべきことに対して最低限しか知らないオブジェクト」、さらに「実行環境やフレームワークのことは一切知らないオブジェクト」といえるのではないか。たとえば、ビジネスロジックを担当するPOJOであれば、自分のするべきこと、まさにロジックと、そのロジックに必要な他オブジェクトのインターフェース（まさに、interface）し
新着記事一覧 やまと、群雄【動】シリーズに『クロノスの大逆襲』からケンリュウが参戦 [02:11 10/13] ASUS、「ASUS PC Park 2008 Powered by Intel」開幕--大阪で最新製品を体験 [21:55 10/12] 小倉優子「消防団は親父も退治してくれます｣ --「地域総合防災力展」が開催 [14:03 10/12] 【レポート】今週の秋葉原情報 - 大容量HDDに注目! 1.5テラが新登場、そして再び8千円切りの1テラも [02:08 10/12] 【インタビュー】「デザイナーがもっと面白く自由になればいい」-クリエイター・長谷川踏太 [21:47 10/11] 仲村みう、生涯"ゴスロリ"宣言 - 「おばあさんになっても続けます!」 [16:25 10/11] 新垣結衣、羽織袴姿で貫禄ポーズ - 映画『フレフレ少女』初日舞台挨拶 [16:0
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
