Zend_Application(2) /Zend FrameworkにおけるDIコンテナ活用のメリットについて/ - noopな日々
PHPでのDIコンテナのわかりやすい説明としては「最小のDIコンテナ in PHP」や「DIコンテナなんていらない」の中で説明されているし、DIコンテナをより詳細に推し進めた形としてはSeasar2のドキュメントか何かを見ていただいた方がいいと思います。DIコンテナは使いこまれた技術で基本概念や実装方法については知られていますので、ここでは、ZFを例にしてDIコンテナを使うメリットについて具体的に検討してみたいと思います。 Zend Frameworkを例にとると 前記事Zend_Application(1) - noopな日々で触れた下記のページにあるように、 http://www.infoq.com/jp/articles/drinking-your-guice-too-quickly DIコンテナはサービスロケーターから進化する流れがわかりやすいわけですが、それらを前提的な話として、
noopな日々
※2.2の変更履歴にありました。 デフォルトのトランスレータを設定するのに、 <?php $translator = $serviceManager->get('translator'); \Zend\Validator\AbstractValidator::setDefaultTranslator($translator); としているケースがありますが、古い設定のままだと、 Argument 1 passed to Zend\Validator\AbstractValidator::setTranslator() must be an instance of Zend\Validator\Translator\TranslatorInterface, instance of Zend\I18n\Translator\Translator given. といったエラーになりました。 変更
Project: MATZ-DI: Matz's Dependency Injection, File: matzdi_block.rb
# Matz DI -- Block Injection # # Usage: # # def start_app # c = DI::Container.new # c.define(:blog) {|c| Blog.new(c.input, c.display)} # c.define(:input) {Input.new} # c.define(:dbms){DBMS.new} # c.define(:markup){Markup.new} # c.define(:plugin){|c| # p = Plugin.new # p.dbms = c.dbms # } # c.define(:display) {|c| # Display.new(c.dbms, c.markup, c.plugin) # } # blog = c.instance(:blog) # end module
簡単なDIコンテナ - Sooey
簡単なDIコンテナ 最小のDIコンテナ in PHP - anatoo勉強記より。 DIコンテナがなにやら大仰なものとして勘違いされているような気がしたので、機能を極限まで削ぎ落とした最小のDIコンテナを書いた。 これにはAOPは当然ないし、設定ファイルなどもない。 30行ほどのコードでDIコンテナっぽい動きを示せているところは素晴らしいです。確かにDIコンテナにAOPは必須ではないし、設定ファイルもできればない方がいいですもんね。 ただ、「最初の取っ掛かり」ということで極限まで簡略化されたのでしょうが、異なるコンポーネント間のDependencyをInjectionできないものはDIコンテナではなくて単なるオブジェクトプールのような気がします。簡単なsetterインジェクションをする場合なら、こんな感じでしょうか。 これはこれで設計的にヘンなところが色々ありますが、このくらいのコードだと
DIコンテナとフレームワークの関係のあるべき姿とは？
► 2013 (1) ► 7月 (1) ► 2011 (1) ► 9月 (1) ► 2010 (3) ► 6月 (1) ► 4月 (2) ► 2009 (15) ► 7月 (2) ► 6月 (1) ► 5月 (3) ► 4月 (3) ► 3月 (5) ► 2月 (1) ► 2008 (22) ► 9月 (1) ► 8月 (5) ► 7月 (4) ► 6月 (1) ► 5月 (2) ► 3月 (1) ► 2月 (5) ► 1月 (3) ▼ 2007 (26) ► 12月 (5) ► 11月 (2) ► 10月 (7) ► 9月 (1) ► 7月 (2) ► 6月 (3) ▼ 5月 (6) DIコンテナは最先端の技術なのか？ WEBアプリのUIコンポーネントの潮流 GPLでライセンスされたライブラリは商用利用できるのか？ DIコンテナとフレームワークの関係のあるべき姿とは？ 何故、今、Ruby
DIコンテナとStrategyパターン
本日のカクテルはDIコンテナです。 こちらのカクテルはオブジェクト指向をベースとしてますので、苦手な方は無理なさらずに。 レシピはオブジェクト指向3/4にStrategyパターンを1/4をステア。マティニのようなショートカクテルに仕上がります。 Java界隈では2004年頃からにわかに熱を帯びていたDIコンテナ(当時はIoCコンテナと呼ばれていた)ですが、一体何者なんだろう？ その掴みどころのなさは、そのメリットがどうにも抽象的に語られるからではないでしょうか。 そのメリットは「オブジェクト間の疎結合」などと言われますが、これはオブジェクト指向を学んだ技術者でも いまいちイメージしにくいメリットです。いや、メリットはわかったとしてもどうやって？そんなものフレームワークになりえるの？ と疑問は尽きない、そんな話だと思うのですね。この胡散臭さが敬遠されているのではないでしょうか。 今回はソース
Solar Framework for PHP 5
Discover Solar is a PHP 5 framework for web application development. It is fully name-spaced and uses enterprise application design patterns, with built-in support for localization and configuration at all levels. Read more about Solar... Download Download the latest release and start using it now, or read the installation instructions. system version 1.1.2 stable as of 2010-11-09
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.makino-style.org/ura/index.php?WhatsDIContainer