TSyringeの使い方とコンテナ登録方法ごとの評価タイミングについて | DevelopersIO
吉川@広島です。 TypeScriptのDIコンテナライブラリはInversifyJSとTSyringeが有名ですが、より機能がミニマムと思われる後者に興味が出たため使ってみました。 https://github.com/microsoft/tsyringe 一番メジャーなInversifyに比べるとTSyringeはやや情報が少ないのと、公式のREADMEもかなりあっさりとしていて使い始める際に戸惑いやすいと思いました。 本記事では、 基本的な使い方 コンテナに登録したクラスのインスタンスをいつ生成しているか を確認したので紹介します。 後者が気になった理由は、DIコンテナへの登録は遅延評価方式に寄せた方がアプリケーション起動時のパフォーマンスに有利に働きやすいと考えるためです。 環境 TSyringe v4.4.0 使い方 import 'reflect-metadata' impor
Container(PSR-11)とsymfony/consoleで簡単なコマンドラインアプリケーションを作ってみよう - istyle Tech Blog
ytake です。 PHPでコマンドラインアプリケーションを開発する時、 いつも使っているフレームワークをそのまま使うには巨大すぎる・・。 という方も多いのではないでしょうか？ 今回は巨大なフレームワークなどを導入せずに、 アプリケーションに合わせて、自分好みのライブラリを組み合わせたり、 簡単なボイラープレートを作成したり、 テストしやすいコマンドラインアプリケーション作りを行うために、 symfony/console と PSR-11 準拠のDIコンテナを組み合わせたコマンドラインアプリケーションの実装例を紹介します。 本エントリに対応したリポジトリは こちら 簡単なコンソールアプリケーションを作る まずは symfony/console をインストールします。 composerを使って下記のコマンドを入力します。 $ composer require symfony/console
Laravel IoC コンテナの使い方
最近は Laravel + AngularJS で Web アプリケーションを開発する毎日です。 少し時間が取れたので Laravel フレームワークのソースを読んでいます。その中から Laravel の肝でもある IoC コンテナの使い方をまとめてみました。 Laravel の IoC コンテナ Laravel で使われている IoC コンテナは、Illiminate\Foundation\Applicationクラスです。これはIlliminate\Container\Containerクラスを継承したもので、コンテナとしての基本機能はIlliminate\Container\Containerクラスが担っています。 Laravel アプリケーションで、この IoC コンテナを利用する際は、AppクラスというIlliminate\Foundation\Applicationのファサード
【PHP】PSR-11 Container Interface（コンテナインタフェース）
公開日 2018.4.30更新日 2020.6.13カテゴリ：PSRタグ：PHP,PSR,Interface,PSR-11,Container PSR（PHP 標準勧告） 概要 PSR-1 Basic Coding Standard PSR-2 Coding Style Guide PSR-3 Logger Interface PSR-4 Autoloader PSR-6 Caching Interface PSR-7 HTTP Message Interface PSR-11 Container Interface PSR-12 Extended Coding Style PSR-13 Hypermedia Links PSR-15 HTTP Handlers PSR-16 Simple Cache PSR-17 HTTP Factories PSR-18 HTTP Client PSR
PHPの各種フレームワークにおけるDIについて - hikyaru-suzuki’s blog
qiita.com QualiArts Advent Calendar 2019、2日目担当の鈴木光です。 タイトルの通り、今回はPHPの各種フレームワークにおけるDIについて書いていこうと思います。 Dependency Injection（DI） あるクラスが依存するオブジェクトをコンストラクタ、メソッド、セッターなどの引数から注入することでクラスから依存関係を減らすという手法です。テストや仕様変更に強くなるという特徴があり、10年以上前から用いられてきたデザインパターンとなります。 ちなみにDIの説明のためにこちらの記事をとても参考にさせていただきました。 やはりあなた方のDependency Injectionはまちがっている。 — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something DIとは DI自体はそ
Pimpleでシンプルに正しくDIを理解する
オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成（オブジェクトコンストラクション）に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
