5

私は、依存性注入、制御の反転、および IoC コンテナーについて多くのことを調べてきました。また、主に動的言語 (職場では PHP、家庭では Python) でプログラミングしています。ここに私が見つけたものがありますが、すべてをつなぎ合わせると、埋めなければならない多くのギャップが残ります。

だから私が読んでいるのは、動的言語でDIを実行する方がはるかに簡単であるため、静的言語ではIoCコンテナーがはるかに大きな取引であるということです。しかし、DI をはるかに超えた利点も提供します。たとえば、依存関係を管理したり、多数のオブジェクトを手作業でつなぎ合わせる必要がなくなるなどです。ついでに言うと、これらは複雑なので、自分でやろうとしないでください (ただし、PHP には適切なものはありません)。

この情報は私をちょっと…行き詰まらせているように感じます。どうすればいいですか？私は非常に複雑な依存関係を持つ非常に大規模なコードベースで作業しています (おそらくリファクタリングが強く必要ですが、それは別の問題です)。これまで DI の実装は非常にうまくいっていませんでしたが、私は本当に正しい方向に向かわせようとしています。動的言語と IoC (または少なくとも IoC コンテナー) に関しては何もないようです。

当分の間、依存関係を「手でつなぐ」方が良いでしょうか。原則をより適切に処理した後、後でコンテナーで自動化することを心配しますか? 独自の単純な IOC コンテナーを実装する価値はありますか? それとも、最終的に PHP のコストに見合うだけのメリットが得られないのでしょうか?

4

5 に答える 5

3

PHPの場合は、Symfonyの依存性注入を試してください。これは（おそらく-私はそれを検証するには経験が少なすぎる）Java Springの動作に基づいていますが、PHPの「魔法」もたくさん使用しています。その結果、非常に軽量で使いやすく、しかも非常に多くのことができます。

于 2011-01-27T21:36:14.817 に答える
1

最初に依存関係の問題を修正します。依存関係を処理するバッグとして IoC コンテナーを使用すると、それほど遠くないところで非常に苦労することになります。

IoC コンテナーは、システム アーキテクチャについて話すための API/語彙を提供する必要があります。

依存性注入により、サブシステムの構成要素として機能する、より小さな分離されたクラスを使用するようになります。これは、ビルディング ブロックを個別にテストし、それらについてより簡単に推論できるため、優れています。（回路内の電子部品のようなものと考えることができます）

IoC コンテナーは、これらのビルディング ブロックの構成を明確に表現する方法を提供する必要があります。(コンポーネントを接続する配線図)

また、この分離により、サブシステムの寿命について考え始めることもできます..ファクトリ、レジストリをいつ使用するか、結合を導入せずにシステム内でメッセージを渡す方法..など.

IOC のポイントは、このすべてのロジックを明示的に述べる場所を提供することであり、魔法のように解決することではありません。

これが役立つことを願っています。

于 2012-01-07T11:52:18.083 に答える
0

過剰に設計されたDICは必要ないが、必要なものすべてを非常にコンパクトな方法で提供するDICが必要な場合は、バケット（https://github.com/troelskn/bucket）を試してください。DIコンテナはそれ以上必要ありません。Symfonyのほかに、サービスロケーター（より良いエイリアスグローバル状態）として、非常に危険な方法で使用されることがよくあります。

于 2011-01-31T00:12:13.217 に答える
0

Martin Fowler が書いたこの記事は、制御の反転と依存性注入の聖書のようなものです。彼は、IoC コンテナーの実装方法を説明し、さまざまな注入メカニズムのメリットについて説明します。http://martinfowler.com/articles/injection.html

使用している言語に関係なく、「依存関係を手動でストリングする」ことはスケーラブルではありません。他の開発者はおそらくすべての手作業のストリングがどこで行われるかを知らないため、維持するのは難しいでしょう。対照的に、これらすべてを 1 か所にまとめることで、将来の変更の実装がはるかに簡単になります。IoC は、コードの繰り返しを最小限に抑え、関心の分離と一貫したアプリケーション アーキテクチャを確保するのに役立ちます。

一方で、かなり大規模な機能しているアプリケーションを手元に置いているように思えます。時間に余裕がある場合を除き、アプリケーションが壊れていなければ、修正する必要はないかもしれません。

于 2011-01-25T21:41:18.343 に答える
0

自分の IoC が他のフレームワークよりも軽量である、または軽量になる可能性があると思われる場合は、それを開発するのに十分な時間があれば、独自のフレームワークを構築してください。ビューをコントローラーにリンクするためだけに、MVC フレームワークで IoC を個人的に使用しています。ビューとそのパラメーターはレジストリ (標準化された構造の連想配列) から管理します。モデルは外部サービスとして処理されます。また、Java で初めて IoC と DI を見つけたので、自分の言語を構築するときに両方の言語 (Java と PHP) から最適なものを取り入れようとしました。もちろん、何もリンクしていませんが、私の場合は必要ありません。あなたもそうではないかもしれません。

IC は時間の経過とともに柔軟性を提供するために重要ですが、どの程度の柔軟性があるのでしょうか? 多くの外部コンポーネントを使用していますか? 標準のプラグインとオブジェクトを使用していますか? PHP は Java ではありません。jar とライブラリの袋が十分に開発されていないため、それをロードして XML のディレクティブを置き換えるだけでいつでも実装できるようになっています。考えてみてください。

私は、Alfresco (ドキュメント管理システム) と呼ばれる例外的なオープン ソース ソフトウェアで優れた IoC 実装を見つけました。JSF、Spring、Hibernate、freemarker のテンプレートを組み合わせた製品ですが、何千ものビジネスモデルに適合することを目的とした製品であり、無限に変更することを目的とした高度なプラットフォームのようなものです。高い柔軟性が必要です。

1 つのビジネス モデルと少数の顧客にサービスを提供することを目的とした、ターゲットを絞ったアプリケーションを開発している場合、IoC の開花に突入すると、物事は単純になるよりも難しくなります。

アインシュタインは、物事は単純でなければならないが、実際よりも単純であってはならないと言いました。

于 2011-01-31T07:33:33.427 に答える