di 依存性注入の実装にはどのような意味があるのでしょうか?

一般的な PHP フレームワークのライフサイクルは次のとおりです。もちろん多少の違いはあるかもしれませんが、ほとんどはこれに過ぎません。

DIインジェクション導入の意義は何ですか？アプリケーションプロセスに関係するオブジェクトをコンポーネントに設計して、分離を実現することですか? RequestInterface/HttpRequest/CliRequest、RouterInterface/SimpleRouter/RegexRouter/MapRouter など?

しかし、ビューとデータベース操作を伴う通常のリクエストの一般的なプロセスは誰でも同じです (ROR / J2EE / PHP MVC)。Router/Request/ControllerAction/Response は分離します。解決した後も、それを取り出して MVC プロセスを形成する必要があります。 Router が Request に依存しているようなので、手動で注入してみてはいかがでしょうか。ルーター コンストラクターのパラメーターは RequestInterface $request?現在のアプリケーション エントリはどのような種類の Request オブジェクトを挿入することを決定しますか? Router がいつか奇妙なガジェットに依存する可能性はありますか?

それは単なる嘲笑の便宜のためですか？それとも不確実な未来のためですか？あるいは他の理由があります。 。 。

返信内容:

一般的な PHP フレームワークのライフサイクルは次のとおりです。もちろん多少の違いはあるかもしれませんが、ほとんどはこんな感じです。

DIインジェクション導入の意義は何ですか？アプリケーションプロセスに関係するオブジェクトをコンポーネントに設計して、分離を実現することですか? RequestInterface/HttpRequest/CliRequest、RouterInterface/SimpleRouter/RegexRouter/MapRouter など?

しかし、ビューとデータベース操作を伴う通常のリクエストの一般的なプロセスは誰でも同じです (ROR / J2EE / PHP MVC)。Router/Request/ControllerAction/Response は分離します。解決した後も、それを取り出して MVC プロセスを形成する必要があります。 Router が Request に依存しているようなので、手動で注入してみてはいかがでしょうか。ルーター コンストラクターのパラメーターは RequestInterface $request?現在のアプリケーション エントリはどのような種類の Request オブジェクトを挿入することを決定しますか? Router がいつか奇妙なガジェットに依存する可能性はありますか?

それは単なる嘲笑の便宜のためですか？それとも不確実な未来のためですか？あるいは他の理由もあります。 。 。

DI についての私の見解は、依存関係の注入よりも依存関係の管理であるということです。実際、DI フレームワークは、アプリケーションとライブラリ間の、composer、pip、ma​​ven などの高レベルの依存関係管理ツールに似ています。利点 (優れた DI フレームワークである場合):

1. 構成を通じて依存インターフェイスの実装を変更します。これはDI機能の最も基本的かつ中心的な機能でもあります

2. 依存する実装、シングルトン、スレッドごとに 1 つ、リクエストごとに 1 つなど、インスタンスのスコープを柔軟に制御します

3. 依存パラメータ、依存依存関係などの管理

4. コードがより簡潔になり、ロジックがより明確になりました

5. Mockはテストに便利です

一般的には、アプリケーション内の関数ブロックとクラス間の依存関係を、統一されたフレームワークを通じて一元管理することです。

そうです、デカップリングです。
MVC の使用によりデカップリングは完了しましたか?
これは最低レベルのデカップリングですよね?

DI の前提は、Bean をホストするために統合されたコンテナーが必要であるということです。そのようなコンテナーがあれば、コードを大幅に変更することなく、内部の Bean に対していくつかの特別な操作を実行できます。これで十分ではないでしょうか。

分離、単体テストに便利、明示的な注入は管理が簡単ですが、最も厄介なのは暗黙的な注入であり、ソース ファイルが長時間見つからないことです。 Laravel の DI は実際にはリクエストとサービスです。