1

applicationcontext.getbeanで diを実行する Bean によって管理されていない Beanと比較して@configurableを使用する利点は何ですか? 誰かが長所と短所を挙げていますか？

4

2 に答える 2

6

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

Service service = new Service();

またはさらに悪い：

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

どちらもコードのテストを困難にします。

于 2009-12-15T01:48:34.187 に答える
1

私はこれで-20を取得します。「依存性注入」というこの恐ろしい名前を発明した悪名高いマーティン・ファウラーでさえ、それがテストに適しているとは考えていませんでした。

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

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

ここに私の異議があります：

  1. DI は、実装の依存関係をインターフェースの依存関係に変えます。あなたのクラスは、他の方法では存在してはならないセッターで汚染されています。確かに、実際のチェックアウト プロセスは、クレジット カード サービス、メール サービス、データベース サービス、そして誰が何を知っているかによって異なりますが、これらの依存関係を宣伝するべきではありません。それらはアドホックでオンデマンドであり、インターフェースに値するものではありません。来月には、チェックアウト プロセス全体が REST 呼び出しだけになるかもしれません。

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

  3. 本番環境のコーディングが難しくなりました。サービスが必要になるたびに、DI を使用するためにどれだけ多くのボイラー プレート コードを追加したかを考えてみてください。すべては、テストを容易にするためです。まず第一に - なに？生産が最優先です。テストは、その逆ではなく、それと一緒に機能する必要があります。テストは宗教ではありません。実稼働環境に集中し、後でテストすることを心配します。第二に、テストは本当に簡単になりましたか?

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

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

結論として、これは設計、パフォーマンス、生産、テスト、標準設定に不適切です。それは何のために良いですか？それは、ずっと前に確立された疑わしい起源の多くのばかげた規則や慣習のようなものですが、私たちは今でも毎日盲目的にそれらに従っています. それが社会を動かしているのです。

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

于 2009-12-15T03:17:35.780 に答える