DIコンテナの設定ファイル書くの？書かないの？
DIコンテナの設定情報，つまり「オブジェクトの依存関係」や「オブジェクトの設定内容」について，規約重視で暗黙のものとするか，ファイルに記述することで形式のものとするかは，個々人によって主張が異なるようである。何が何でも設定ファイルを書かない，あるいは，何が何でも設定ファイルを書く，といった「原理主義者」も多く，多くの場合は彼らの説明に「コンテキスト」が含まれない。よって，主張を聞いても，実際に何らかのDIコンテナを使う際をイメージした場合，その主張に沿う部分と沿わない部分が僕個人の中で発生し，完全に主張を受け入れられないことがよくある。
結局のところ「DIコンテナをどう使うか」（＝上記で言ったコンテキスト）によって，暗黙知とするか形式知とするかを判断しなければならないと思っている。
DIコンテナの適用パターンとして代表的なものは，「View，Business Logic，Dao」といった3層アプリケーションのレイヤ間結合だろう。各層に存在するオブジェクトを1対1で依存させるためにDIコンテナを使う。この場合，インジェクションさせたいオブジェクト，つまり特定のインタフェースの実装クラスは，システム内で１つに決定し，それは設定ファイルに記述するまでもなく実行時（＝システムの起動時？）に動的に検索して依存性の自動解決をしてあげるほうが都合が良い。レイヤ間結合のためにオブジェクトの1対1関係をセコセコ設定ファイルに記述する手間は，想像以上だ。この場合は，オブジェクトの依存関係は暗黙知としても良いと思っている。Seasar2のように設定ファイルを書かない暗黙知の実装でもいいし，手で書かないという点では，設定ファイルの自動生成でも良いだろう（開発者が意識しないという点では暗黙知として良い）。
しかし，DIコンテナの使い方によって「形式知とすべきケース」「しなければならなくなるケース」も存在する。
DIコンテナの設定情報は，何も3層アプリのレイヤ間結合だけではない。時として，実行時の処理ロジックも決定されることがある。例えば，昔以下のような設定ファイルを書いたことがある。
ダブル定額
通常従量制
計算ロジックは，設定ファイル上でリストコレクションとして計算ロジックの実装クラスに依存性注入される。計算ロジックの実装クラス内で，注入されたリストコレクション内のロジックを順次実行するようにコーディングされていた場合，処理順序は設定ファイル上に明記しなければならない。これは暗黙知として実現できないケースと言えるだろう。つまり，この場合は「設定ファイルに記述しなければならない」ことになる。
あとは，上記のようにXML上での表現で十分か，スクリプト言語で呼びだし順序に制御を持ち込むか，を判断すれば良いだろう。
上記の課金パターンリストは，名前とロジッククラスの組み合わせのみであるので，暗黙知としても良いかも知れない。しかし，仮に上記システムのカスタマイズが発生し，あるお客さんから「ダブル定額はいらないよ」と言われてしまった場合は，不足の事態を避けるためにも，上記の定義から除外しなければならないだろう。その場合，暗黙知として自動インジェクションとしていた場合は，「ダブル定額を除外する」という記述をすることになるが，個人的には「除外するもの」よりも「適用されるもの」が書かれていた方が安心する。つまり，「形式知とすべき」ケースだと思うのだが，ま，これについてはグレーゾーンかもしれない。
DIコンテナをBPELやワークフローエンジン的な使い方とする場合には，形式知の方が向いているし，形式知として明記しないとそもそも実現できない。
「 ひがやすをblog」の「 規約ベースのフレームワークのほうが覚えることが増える?」において，
なにも記述していないのに、全部自動的に処理されて不安という気持ちもわかりますが､せっかくコンピュータを使っているんだから､楽できるのは楽をすればというのが私の考えです。
と書かれているが，これは上記の例でいう「3層アプリでのレイヤ依存関係の設定内容」について当てはまり，さらに「 arclamp.jp」ブログの「 それでも設定が大事な理由」において，
しかし、設定ファイルに設定する増えてくると、今度は設定ファイルにコード（で書かれたコンポーネント）が組み込まれているような感覚になってきます。一方のフレームワークはコンテナ化してきて、アプリケーションの動作でもローレベルなコンポーネントの生成管理、メッセージルーティングのような仕組みだけを提供しています。
と書かれているが，これは上記の例でいう「形式知すべき（しないといけない）設定内容」について当てはまると思う。つまり，DIコンテナの利用パターンというか，着眼点，重視している点が，両者で違っているのではないかと。
世間一般には「全部書くか，全部省略するか」で語られることが多いが，ハイブリッド，つまり「この問題領域は暗黙知，もう一方の問題領域は形式知」というのが現実解。そして，開発チームのロール毎にどちらを適用するかを決定し（大量生産部分は暗黙知，めっちゃ難しい部分は形式知，とか），形式知とする箇所においてどのような設定を施すか，どのように設定を表現（記述）するか，システムの成長に対する答えをどういった形式知として盛り込んでおくか，ということを考えることが，今日のITアーキテクトが最も面白いと感じる部分ではないかと思う。
DIコンテナは，開発に対して柔軟性を提供してくれる。そして「DIコンテナをいかに柔軟に使いこなせるか」についても，より大事なことである。両者のエントリは，そのことを再認識させてくれた。
