2

依存性注入 (DI) は、複数のチーム メンバーがいる大規模なエンタープライズ アプリケーションにとってより重要なものですか? 現在、私は 1 人の開発者として、小さなサイトをハッキングして、それが勢いを増しているかどうかを確認しようとしています。しかし、DI が私が書いているコードに付加価値をもたらすとは確信していません。このコミュニティからは圧倒的な支持を得ています。

私は先週、DI の調査とコードへの実装に費やしましたが、時間のかかるだけで難しいことではありません。しかし、デカップリングと単体テストの利点はまだわかりません。代わりに、コードの理解が難しくなり、作成に時間がかかり、パフォーマンスの問題が発生する可能性があります。DI の実装にこれ以上時間を費やす前に、次の問題に対処することに関心があります。

1) デカップリングの利点は? DI によってコードの依存性が低下する仕組みがわかりません。コードはその性質上、機能するために相互に依存する必要があります。DI は、この依存関係を表示されない別の領域に移動するだけです。たとえば、別の静的メソッドを呼び出すメソッドがあるとします。

class User {

// Static Dependency //
function process_registration() {
    if(Form::validate($_POST['email'])) {
        Message::send_message("Registration Complete");
    }
}

// Dependency Injection //
function __construct($form, $message) {
    $this->form = $form;
    $this->message = $message;
}
function process_registration() {
    if($this->form->validate($_POST['email'])) {
        $this-message->send_message("Registration Complete");
    }
}
}

DI は、とクラスprocess_registrationに対する の依存関係を変更しません。それらが「ユーザー」クラスにプロパティとして注入されたとしても、そのクラスのプロパティに依存して動作することはありませんか? さらに、「ユーザー」クラスにプロパティを注入するコンテナがあった場合、そのメソッドもそのクラスをインスタンス化するためにコンテナに依存しませんか? 将来、「process_registration」を別のクラスにリファクタリングするか、別のプロジェクトで再利用したとします。同じクラス プロパティとインジェクション コンテナーが存在しない可能性があるため、DI が使用されているかどうかに関係なく、メソッドは機能しなくなります。FormMessageprocess_registration

2) コードの読みやすさ? 上記の例からわかるように、process_registrationメソッドに必要なコードは 2 倍になりました。新しいクラスをインスタンス化するたびに、またはクラス メソッドを変更するたびに、Container クラスを変更する必要があることを考慮すると、2 倍以上になります。それを除けば、コードは直感的ではなくなりました。$database、$form、などのプロパティは とどのように$message関連していUserますか? コードもエレガントではありません。以前は、静的メソッドは!Form::validate(), 2 語でした。今では$this->form->validate()、30% 長くなりました。これは、クラスに注入したすべてのメソッドに影響します。$this->そのため、コードのページを見ると、$this->すぐ$this->に説明できる静的メソッドではなく、100 回繰り返されています。$user=new User($user_id);今の代わりにioc::get('user')->newUser($user_id);. 私が言いたいのは、DI は非 PHP 標準の慣用的なコードを奨励するということです。

3) より良いパフォーマンス? DI は、使用する準備が整ったときに Just In Time メソッドを呼び出すのではなく、決して使用されない可能性があるオブジェクトのインスタンス化を促進します (たとえば、検証が失敗した場合やエラーがスローされた場合)。これらのオブジェクトに巨大なライブラリがあり、読み込みが重い場合 (PHPExcel など)、これはパフォーマンスの問題になる可能性があります。これに対する回避策は何ですか？

4) 単体テスト? 小規模から中規模のプロジェクトにコードのテストは必要ですか? 現在、PHP はコードにエラーがあると通知してくれます。これらは通常、error_log を確認することで、特定して修正するのが非常に簡単です。将来、プロジェクトをスケールアップする必要がある場合、これは問題になりますか? そうでない場合、テスト目的で DI が必要になるのはいつですか?

上記の理由から、プロジェクトに DI を実装する必要がないことがわかりました。ただし、適切に実装できるように、いつ、どこで実装する必要があるかについては関心があります。あなた自身の詳細な例を挙げて、推論をサポートしてください. 他の記事へのリンクには興味がありません。前もって感謝します！

4

1 に答える 1

0

1) Form クラス名を変更したいとします。DI を使用した場合は、Form クラスをコンテナーに登録するときに、1 か所だけ変更する必要があります。

コンポーネントを分離しているため、DI を使用した単体テストは簡単です。User、Message、および Form クラスを個別にテストできます。あなたの例では、 Message および Form クラスなしで User クラスをテストすることはできません。

2) 可読性は関数/可変長に関するものではありません。コンストラクターを見ると、あるクラスでどの依存関係がどのように使用されているかが明確にわかるため、DI は読みやすさを向上させます。

3) 共有オブジェクトを許可しない単一の DIC を知りません - 一度だけインスタンス化し、要求に応じて (遅延読み込み)。

4) 1を参照してください。

于 2013-01-11T09:05:36.770 に答える