applicationcontext.getbean と @configurable を使用する利点 [終了]

Question

使用する利点は何ですか @configurable オンと比較して di を実行する Bean によって管理されない Bean による アプリケーションコンテキスト.getbean?長所と短所を挙げた人はいますか？

Answer 1

もらいます -20 このために。「Dependency Injection」というこの恐ろしい名前を発明した悪名高い Martin Fowler でさえ、これがテストに適しているとは考えていませんでした。

http://martinfowler.com/articles/injection.html

依存関係の注入を好む一般的な理由は、テストが容易になるからです。ここで重要なのは、テストを行うには、実際のサービス実装をスタブまたはモックに簡単に置き換える必要があるということです。ただし、依存関係注入とサービス ロケーターの間に実際には違いはありません。どちらもスタブ化に非常に適しています。この観察は、サービス ロケーターを簡単に置き換えることができるように人々が努力していないプロジェクトから来ているのではないかと思います。ここで継続的なテストが役立ちます。テスト用のサービスを簡単にスタブできない場合は、設計に重大な問題があることを意味します。

私の反対意見は次のとおりです。

1. DI は、実装の依存関係をインターフェイスの依存関係に変換します。クラスは、本来存在すべきではないセッターで汚染されています。確かに、実際のチェックアウト プロセスは、クレジット カード サービス、メール サービス、データベース サービス、そして明日何が起こるかわからないことに依存していますが、これらの依存関係を宣伝すべきではありません。これらはアドホック、オンデマンドであり、インターフェースに適したものではありません。おそらく来月には、チェックアウト プロセス全体が REST 呼び出しのみに減るかもしれません。

2. パフォーマンス。通常、サービスは 1 つのメソッドの外側では必要ありません。DI にはサービスごとに少なくとも 1 つのフィールド変数が必要で、ホスト オブジェクトが生きている限り参照されます。サービスにクライアントごとの状態がある場合、これは非常に問題です。私はパフォーマンスに敏感な人間ではありませんが、これは間違っていると感じます。

3. 本番環境のコーディングがさらに難しくなりました。サービスが必要になるたびに、DI を使用するためにどれだけ多くの定型コードを追加したかを考えてください。すべてはテストを容易にするという名目で行われます。まず第一に - 何?!生産が最優先事項です。テストは、その逆ではなく、それに対して、そしてそれとともに機能する必要があります。 テストは宗教ではありません、皆さん！ 本番環境に集中し、テストについては後で考えてください。第二に、テストは本当に簡単になりましたか?

4. テストでは、負荷が高く VM 以外のアクティビティを伴ういくつかのサービスをモックするだけで済みます。サービス ロケーターを使用すると、それらのモック サービスを含むテスト構成が作成され、完了です。チェックアウト プロセスと、それらのサービスに依存するすべてのクラスを手間をかけずにテストできます。DI では、これらの依存関係を手動で管理する必要があります。 それぞれ 単体テスト。-しかし！しかし、DI を使用すると、さまざまなテスト単位にさまざまな模擬メール サービスを提供できる柔軟性が得られます。ああ、よかったね！

5. 「DI はサービス構成の統一的な方法を奨励します」 - 場合のみ 同じフレームワークを使用します。実際には、これは DI とは何の関係もありません。フレームワークは 1 つの構成方法を強制するものであるため、Spring はサービスを特定する統一的な方法を奨励していると主張することもできます。フレームワークが広く使用されるようになると、それが事実上の標準になる可能性があるため、さまざまな開発者が互いに話し合うことが容易になります。これはネットワーク効果によるものであり、その設計の選択が本質的に優れているためではありません。

結論として、それは設計にとっても悪いことであり、パフォーマンスにとっても悪いことであり、本番環境にとっても悪いことであり、テストにとっても悪いことであり、標準の設定にとっても無関係です。何に良いのですか？それは、はるか昔に設立された、起源が疑わしい、たくさんのばかげたルールや慣習のようなものですが、私たちは今でもそれらを盲目的に毎日に従っています。それが社会を動かしていくのです。

編集:DI とテストに関する新しい質問への転送リンク 注釈を使用して依存関係を注入すると、依存関係の注入 (外部構成) の主な利点が失われますか?

Answer 2

やってる applicationContext.getBean() ～の目的を完全に裏切る 依存性注入 依存関係を注入しなくなったからです。アプリケーション コンテキスト XML ファイルは問題ありません。注釈ベースの構成 (自動配線) も問題ありません。このようにして、次のようにすることもできます。

Service service = new Service();

あるいはさらに悪いことに：

Service service = ServiceLocator.locate("service");

どちらの場合も、コードのテストが困難になります。