[解決済み】Spring @Autowired の使い方

質問

を使うことの長所と短所を教えてください。 オートワイヤード を、Springによって配線されるクラスで使用することはできますか？

はっきりさせておきたいのは、具体的には オートワイヤード アノテーションであり、XMLにおける自動配線ではありません。

私が理解していないだけかもしれませんが、私にはアンチパターンのように思えます。クラスが単なるPOJOではなく、DIフレームワークと結びついていることを意識し始めるからです。 私は大食漢なのかもしれませんが、ビーンに外部 XML 設定を持たせるのが好きですし、配線が明示されているのが好きなので、何がどこに配線されているのかがよくわかります。

解決方法は？

長い間、私は、私たちが使っていたxmlファイルのような、一元的で宣言的な設定を持つことに価値があると信じていました。しかし、ファイルに書かれていることのほとんどが、「宣言的」ではなく「設定的」であることに気づきました。 コンフィギュレーション - 開発後に変更されることは一度もありませんでした。そして、quot;centralized" は非常に小さなシステムにおいてのみ価値があることに気づきました - 小さなシステムにおいてのみ、設定ファイルを理解することができるのです。 全体として . そして、同じ配線がコード内の依存関係によって重複している場合、配線全体を理解することの本当の価値は何でしょうか。そこで、私が唯一残しているのがメタデータ（注釈）で、これはまだ一種の宣言的なものです。これらは 決して は実行時に変更され、それらは 決して 誰かがその場で変更するようなデータなので、コードに残しておくのはいいことだと思います。

私はできるだけフルオート配線を使用しています。大好きです。銃で脅されない限り、旧式のスプリングに戻ることはないでしょう。私がフルオート配線を好む理由 @Autowired は、時代とともに変化しています。

今現在、autowiringを使用する最も重要な理由は、システム内で追跡しなければならない抽象的な要素が1つ減ることだと思います。ビーン名("bean name")は事実上消滅しています。ビーン名はxmlのためにのみ存在することが判明しています。つまり、抽象的な間接参照（bean-name "foo" を bean "bar" に配線する）の完全な層がなくなったわけです。現在、私は "Foo" インターフェイスを直接ビーンに配線しており、実装はランタイムプロファイルによって選択されます。これにより、以下のことが可能になります。 コードで作業する 依存関係や実装をトレースする際に 私のコードで自動配線された依存関係を見つけたら、IDE で "go to implementation" キーを押すだけで、既知の実装のリストが表示されるのです。ほとんどの場合、実装は1つだけで、そのままクラスに入ることができます。これほど簡単なことはありませんし、私は常に まさに どのような実装が使われているのか(xml 配線では逆の方が真実に近いと主張していますが、視点が変わるのは面白いですね！)

これは非常に単純なレイヤーだとも言えますが、私たちがシステムに追加する抽象化のレイヤーは、それぞれ 増加 複雑なのです。xmlは、私がこれまで手がけたシステムの中で、本当の意味で価値を高めてくれたとは思えません。

私がこれまで関わってきたほとんどのシステムは 一 の構成は、本番環境の実行環境と同じです。テスト用など、他の構成もあるかもしれません。

完全自動配線は、Springのruby-on-railsのようなものだと思います。ほとんどのユースケースが従う、正常で一般的な使用パターンがあるという概念を受け入れているのです。XMLコンフィギュレーションでは 許可 意図しているかどうかに関わらず、一貫性のある、あるいは一貫性のない設定の使い方が多くなっています。私は、多くのxmlコンフィギュレーションが不整合で行き過ぎるのを見たことがあります - それはコードと一緒にリファクタリングされますか？そうではないと思います。そのようなバリエーションには理由があるのでしょうか？通常はそうではありません。

私たちの構成では、修飾語はほとんど使用せず、このような状況を解決するために他の方法を見つけました。これは明らかにデメリットです。自動配線とスムーズに連動させるために、コーディングの方法を少し変更しました。顧客のリポジトリでは、一般的な Repository<Customer> インターフェイスを作るが、インターフェイスを作る CustomerRepository を拡張する Repository<Customer> . また、サブクラス化する際にコツがいることもあります。しかし、それはたいてい、より強力な型付けをする方向を示しているだけで、私はほとんどの場合、より良い解決策だと考えています。

しかし、そうですね、ほとんどspringが行っているDIの特定のスタイルに縛られていますね。私たちはもう依存関係に対してパブリックなセッターを作ることさえしません（ですから、カプセル化/情報隠蔽の分野では+1だと言えるかもしれません）私たちのシステムにはまだいくつかのxmlがありますが、xmlは基本的に のみ には異常が含まれています。完全な自動配線は、xmlとうまく統合されます。

今必要なのは @Component , @Autowired で、残りはJSRに含まれるようにする（例えば JSR-250 というように、春と結びつけなくてもいいのです。というのが、これまでの流れです( java.util.concurrent また同じようなことが起きても、まったく不思議ではありません。