Spring @Autowiredの使用
Springによって接続されるクラスで@ Autowiredを使用することの長所と短所は何ですか？
明確にするために、XMLでの自動配線ではなく、@ Autowiredアノテーションについて具体的に説明しています。
私はおそらくそれを理解していないかもしれませんが、私にとってはほとんどアンチパターンのようです-あなたのクラスは、単にPOJOであるのではなく、DIフレームワークに関連付けられていることに気付き始めます。たぶん私は罰のための大食いですが、私は豆のための外部XML構成を持つのが好きで、明示的な配線が好きなので、どこで何が配線されているかを正確に知っています。
長い間、私はみんなが使用していたxmlファイルのような「集中化された宣言的な構成」を持つことに価値があると信じていました。それから、ファイル内のほとんどのものがconfigurationではないことに気付きました-開発後、どこにも変更されませんでした。それから私は、「中央集中型」は非常に小さなシステムでのみ価値があることに気付きました-小規模なシステムでのみ、構成ファイルを全体として見ることができます 。また、コード内の依存関係によって同じ「配線」がほとんど重複している場合、配線全体を理解することの実際の価値は何ですか？そのため、私が保持しているのはメタデータ（注釈）だけです。これは、まだ一種の宣言です。これらneverは実行時に変更され、それらはnever「構成」データです誰かがその場で変更するということです。そのため、コード内でそれを維持することは素晴らしいと思います。
可能な限り完全自動配線を使用しています。大好きです。銃口で脅かされない限り、私は古いスタイルの春には戻りません。完全に@Autowiredを好む理由は、時間の経過とともに変わりました。
現時点では、自動配線を使用する最も重要な理由は、追跡するシステムの抽象化が1つ少ないことです。 「Bean名」は事実上なくなりました。 Bean名はxmlのためにのみ存在することがわかります。したがって、抽象インダイレクションの完全な層（Bean名 "foo"をBean "bar"にワイヤリングする場所）はなくなりました。ここで、「Foo」インターフェースを直接Beanに配線し、実行時プロファイルによって実装が選択されます。これにより、依存関係と実装をトレースするときにcodeを操作できます。コードに自動配線された依存関係が表示されたら、IDEの「実装に移動」キーを押すだけで、既知の実装のリストが表示されます。ほとんどの場合、実装は1つだけであり、私はクラスに直接入ります。それよりもはるかに簡単にすることはできず、私は常にexactlyどの実装が使用されているかを知っています（反対はxmlで真実に近いと主張します配線-視点がどのように変化するかおかしい！）
これは非常に単純なレイヤーであると言えますが、システムに追加する抽象化の各レイヤーincreaseの複雑さです。 xmlがこれまでに使用したシステムに実際の価値を追加したとは本当に思わない。
私がこれまでに使用したほとんどのシステムには、実稼働ランタイム環境の構成がoneしかありません。テストなどのために他の構成があるかもしれません。
完全自動配線は春のRuby-on-Railsであると言えます。これは、ほとんどのユースケースが従う通常の一般的な使用パターンがあるという概念を包含しています。 XML構成を使用すると、permit意図した/意図しない可能性のある多くの一貫した/一貫性のない構成の使用を許可します。私は非常に多くのxml構成が一貫性のない状態で行き過ぎているのを見ました-コードとともにリファクタリングされますか？とは思いませんでした。これらのバリエーションは理由がありますか？通常はありません。
構成では修飾子をほとんど使用せず、これらの状況を解決する他の方法を見つけました。これは私たちが遭遇する明らかな「欠点」です：自動配線とスムーズにやり取りするようにコードの方法を少し変更しました：顧客リポジトリはもはや汎用Repository<Customer>インターフェースを実装しませんが、Repository<Customer>を拡張するインターフェースCustomerRepositoryを作ります。サブクラス化に関しては、1つまたは2つのトリックもあります。しかし、それは通常、より強力なタイピングの方向に私たちを向けるだけであり、ほとんどの場合、それはより良い解決策だと思います。
しかし、はい、あなたは主に春が行うDIの特定のスタイルに結びついています。依存関係の公開セッターも作成しません（カプセル化/情報隠蔽部門で+1であると主張できます）システムにはまだxmlがありますが、xmlは基本的にonlyには異常が含まれます。完全自動配線は、xmlとうまく統合されます。
ここで必要なのは、@Component、@Autowired、および残りをJSRに含めることだけです（ JSR-25 など）。したがって、春と結び付ける必要はありません。これは過去に起こったことでした（Java.util.concurrentが思い浮かぶ）、これが再び起こっても私はまったく驚かないでしょう。
私にとっては、Springと自動配線について私が好き/嫌いなものです。
長所：
- 自動配線は厄介なXML構成を取り除きます。
- フィールド、セッターメソッド、またはコンストラクターを使用して直接注入できる注釈の使用がはるかに簡単になりました。また、注入されたBeanに注釈を付けて「修飾」することもできます。
短所：
- 自動配線と注釈を使用すると、XML構成と同様に、Springの有無に関係なく実行できるSpringライブラリに依存するようになります。あなたが言ったように、あなたはDIフレームワークに縛られるようになります。
- 同時に、Beanを「修飾」できることが好きです。これにより、コードが非常に面倒になります。同じBeanを複数の場所に挿入する必要がある場合、同じ文字列名が繰り返し表示されています。私には、これにはエラーの可能性があるようです。
とにかくSpringの統合に非常に依存しているため、依存関係の問題は議論の余地がないため、私は職場でほぼ独占的に自動配線の使用を開始しました。私は自動配線を広範囲に使用するSpring MVCプロジェクトに取り組みましたが、頭を包むのは少し困難でした。
自動配線は習得済みの味だと思います。慣れると、XML構成よりも強力で簡単で、頭痛が少ないことを実感できます。
大きなプロジェクトでは、@ AutowireからXML構成に切り替えています。問題は、bootstrapのパフォーマンスが非常に低いことです。自動配線スキャナーは、自動配線検索クラスパスからすべてのクラスをロードするため、Springの初期化中に多くのクラスが積極的にロードされます。
環境の切り替えについてはほとんど議論されていません。私が取り組んできたほとんどのプロジェクトは、私たちが取り組んでいる環境に応じて依存関係を注入するという本当の問題でした。 xml configを使用すると、Spring ELを使用するのは非常に簡単であり、アノテーションを使用したニースのソリューションを認識していません。私は1つを見つけました：
@Value("#{${env} == "production" ? realService : dummyService}")
private SomeService service;
動作するはずですが、ナイスなソリューションではありません。
@Autowireに切り替えました。小さなプロジェクト以外でXML構成を維持することは、それ自体がタスクとなり、理解度は急速に低下しました。
IntelliJは、Spring注釈に対して適切な（完全ではない）サポートを提供します。
このテーマに関する私の見解は、特に大規模システムでは、xml構成によりコードの明瞭さが低下するということです。
@Componentのような注釈は事態をさらに悪化させます。デフォルトのコンストラクターを提供する必要があるため、依存関係を最終的にはできないため、開発者はオブジェクトを可変にできます。依存関係は、パブリックセッターを介して注入するか、@ Autowiredを介して制御しないようにする必要があります。 [依存関係のインジェクションは、依存関係をインスタンス化するクラスによってさらに悪化します。これは、新しく作成されたコードでも見られます！]制御されていないということは、大規模なシステムでは、そのタイプの複数の実装（または子）が利用可能な場合、どの実装が@Autowiredであるかを理解するためにより深く関与し、バグの調査をより困難にする複雑さを意味します。また、おそらくテスト環境用のプロファイルと本番用のプロファイルがあるため、本番環境のバグは、テスト環境でバグを見つけることはできませんが、本番環境で最も痛いときにのみ発生します。コンパイル時間！
私は自分の設定クラスを宣言する中間点に固執します（@Configurationを使用したJavaベースのSpring設定）
すべてのBeanを構成クラスで明示的に宣言します。私は構成クラスで@Autowiredのみを使用します。目的は、Springへの依存を構成クラスに制限することです
@Configurationは特定のパッケージにあり、これがスプリングスキャンが実行される唯一の場所です。 （大規模プロジェクトでは開始時間が大幅に短縮されます）
私はすべてのクラス、特にデータオブジェクト、JPA、Hibernate、Spring、および多くのシリアル化ライブラリを不変にするように努力しています。私は、セッターを提供することを余儀なくされるもの、またはプロパティ宣言から最終的なキーワードを削除することを強制するものから遠ざかります。
作成後にオブジェクトを変更する可能性を減らすことで、大規模システムのバグを大幅に減らし、バグが存在するときにバグを見つける時間を短縮します。
また、開発者がシステムの異なる部分間の相互作用をより良く設計することを余儀なくされているようです。問題やバグはますます多くのコンパイルエラーになり、無駄な時間が減り生産性が向上します。
私はXMLの代わりにアノテーションを使って書くのが大好きです。 Springマニュアルと最新バージョンによると、XMLと注釈は同じ結果を達成しました。
これは私のリストです
プロ：
- XMLから無駄な行を削除
- コードのデバッグを簡素化する：クラスを開くと、クラスにあるものを読むことができます
- より高速な開発、400行以上のXMLを含むプロジェクトは読み取り可能ですか？
短所：
- 標準のJava実装ではありませんが、Java標準APIである@Injectを使用するように切り替えることができるため、BeanはPojoのままです。
- どこでも単純にdb connection eを使用することはできませんが、それは単なる意見であり、すべての構成を読み取る場所があることを好みます。
ここにいくつかの経験があります
長所
- @Autowireアノテーションのみを使用できるため、構成が容易になります。
- セッターメソッドを使用したくないので、クラスはよりクリーンになります
短所
- DIを使用している場合でも、xmlファイルに密結合
- 実装を見つけるのは難しい（ただし、intellijのような適切なIDEを使用している場合は、これを取り除くことができます）
私の個人的な経験では、テストケースでは@AutoWireアノテーションをあまり使用しませんでした。
私の理解では、@ Autowiredはインターフェイスリファレンスを参照し、そのオーバーライド機能を使用するときに使用するのが最適ですが、これに関する問題は、実行時にnullに割り当てられることがあるということだけです。