序文
Java開発に従事するコーダーとして、春の重要性は自明です。あなたは毎日春のフレームワークを扱っているかもしれません。春は名前が付けられており、Javaアプリケーションの開発に春のような快適さをもたらします。春は、Java開発者が高度な技術に到達するために必要な基盤であると言えます。もちろん、特に春の根底にある原則を理解するために、春をよく学ぶことは容易ではありません。それを慎重に研究するには多くの時間とエネルギーが必要であり、あなた自身の思考と理解を形成するために、実際のプロジェクトで常に試行錯誤し、要約します。ブロガーは最初は春を非常に浅く理解していたので、プロジェクトで問題に遭遇したときに、デュニャンが一般的に解決できる問題に頼ることができました。しかし、春が春と接触してから1年以上にわたり、そのフレームワークシステムの理解は非常に混oticとしており、深い技術はまだ霧のようであり、プログラミングテクノロジーの改善に非常に不利な独自の認知と理解を形成していません。これを考慮して、私は落ち着いて、最初から最後までSpringフレームワークを体系的に学び、学習の詳細を記録し、ブログの形式で技術的な知識を共有することにしました。さて、ポイントに行きましょう -
コアスプリングフレームワークの紹介
DI（依存関係注入）、依存関係注射、および私たちがよく聞く別の概念は、実際にIOC（制御反転）と同じ機能を実装していますが、同じ機能が異なる観点から説明されています。ここのブロガーはあまり分析することはありません。Baiduには多くの説明があります。私たちが知る必要があるのは、依存関係の噴射とは何か、依存関係噴射がなぜあるのかということです。これらの2つのポイントを理解するために、私は春を学ぶことが思考の観点から最高だと思います。
スプリングが使用されない場合 - つまり、依存関係の注入がない場合、Javaアプリケーションのクラス間の相互の機能的コラボレーションを達成することは困難です。特定のクラス（a）が関数を実装する必要がある場合、別のクラス（b）のコラボレーションに依存する必要がある場合は、クラスBメソッドを使用して機能を完了するためにクラスAにクラスBオブジェクトを積極的に作成する必要があります（ここで静的な方法やその他の状況について心配する必要はありません）。これは、クラスBオブジェクトのライフサイクル全体の管理に責任があるクラスAに相当します。非常に単純な場合、あるクラスの別のクラスの新しいオブジェクトには問題はないようですが、複雑なアプリケーションクラスとクラスの間の共同関係はしばしば多国間です。クラス関数の実装が協力するために依存する代替オブジェクトの数がわかりません。したがって、クラスでオブジェクトを作成し、オブジェクトのライフサイクル全体を管理すると、高いコードの結合と想像を絶する複雑さが発生します。したがって、オブジェクトのライフサイクルを管理のためにサードパーティコンポーネントに渡すことができれば、クラスが別のオブジェクトを必要とする場合、サードパーティのコンポーネントが直接作成されると想像してください。このようにして、クラスは他のクラスオブジェクトのライフサイクルを管理せずに独自の関数の実装にのみ焦点を当てることができ、そのようなクラスの機能ははるかに簡単です。はい、あなたは春がこのサードパーティのコンポーネントであることを理解していたに違いありません。どのオブジェクトを管理する必要があるかをSpring（コンテナ）に伝える必要があり、Springフレームワークがオブジェクトを作成する方法を気にする必要はありません。このようにして、特定のクラスAにクラスBオブジェクトが必要な場合、クラスBが宣言され、スプリングコンテナ管理に引き渡された場合、プログラムはクラスAに実行され、クラスBを必要とする場合、スプリングコンテナはクラスBオブジェクトをクラスAに依存噴射に注入し、ビジネス機能を完了するのを支援します。サードパーティのコンポーネントの依存関係を通じて、オブジェクトはクラス自体間で依存関係を作成および管理する必要がなくなりました。また、インターフェイスインジェクション、建設方法インジェクション、セッターメソッドインジェクションなど、オブジェクトの依存関係注入を作成する方法も多くあります。これについて言えば、依存関係の注入を比較的簡単に理解する必要があります。依存関係の注入が必要な理由については、上記の記事はすでに非常に明確に説明しています。コード内のコンポーネント間の結合を減らすために、最初に簡単な例を使用して、自分でオブジェクトの管理よりも依存関係の注入の利点を直感的に体験する必要があります -
パブリッククラスの男は人間を実装します{プライベートqqcar車。 public man（）{this.car = new qqcar（）; } @override public void xiabibi（）{} public void drivecar（）{car.drive（）; }}インターフェイスカーには、メルセデスベンツとQQ車の2つの実装があります。上記のMANおよびQQCARのコードでは、ベテランドライバーはコンストラクターを介してQQ CARオブジェクトを作成したため、QQ車のみを運転することができます。では、ベテランの運転手はメルセデス・ベンツを運転したい場合はどうすればよいでしょうか？メルセデスベンツオブジェクトを再現するように彼に頼みますか？このような高度に結合されたコードは無力であるように思われるため、オブジェクトを注入することにより、上記のコードを改善します。
パブリッククラスの男は人間を実装しています{自家用車。パブリックマン（カーカー）{this.car = car; } @override public void xiabibi（）{} public void drivecar（）{car.drive（）; }}上記のコードは、コンストラクターインターフェイスインジェクションを介した多型特性に基づいて特定のオブジェクトをブロックし、ベテランドライバーが好きなものを運転できるようにします。これは、依存噴射の利点です。
AOP（アスペクト指向プログラミング）、対面プログラミング。毎日の開発では、特定のビジネス機能を完了すると、多くのコードを書きます。コードを最終的に最適化すると、実際にビジネスを完了するコードはわずか2文である可能性があり、残りはビジネスのこの部分にあまり関連していないことがわかります。特定のテクノロジーコードを実装するためだけに完全に抽出されます。そのため、当然のことながら、ツールメソッドを呼び出すだけで使用するものはすべて問題ないように、ツールクラスに抽出します。少し高く見てみましょう。関連するビジネス機能の完了に加えて、各ビジネスモジュールの機能コンポーネントには、ログ、トランザクション、セキュリティ制御などの追加の操作が含まれます。これらはモジュールのコア関数ではありませんが、不可欠です。これらの追加機能がコードに追加された場合、ビジネスシステムの各コンポーネントはあまりにも繰り返し表示され、ビジネスコードが混乱し、十分に純粋ではないように見えます。この時点で、あなたは神に尋ねます、あなたのビジネスコードはビジネスの実装にのみ焦点を合わせ、ログ、トランザクションなどの無関係なものを無視することができますか？ああ、神はそれが大丈夫だと言ったので、AOPがありました。依存噴射の目的が、協同組合のコンポーネントを比較的緩い結合状態に保つことである場合、AOPはアプリケーション全体に広がって再利用可能なコンポーネントを形成する機能を分離します。素人の用語では、ログ、トランザクションなどはすべて再利用可能なコンポーネントです。ビジネスコードのさまざまな部分に散在するログ、トランザクション、セキュリティ、その他の機能コードを完全に抽出し、別のツールコンポーネントになることができます。 Springの構成の機能セクションとして宣言し、これらの再利用可能なコンポーネントをどこで、いつ使用する（カットして）springに伝えます。これは、顔指向のセクションの私の単純な解釈です。この記事は単なる紹介であるため、ブロガーは概念を簡単に説明し、特定のコードまたは構成の実装を行いません。その後のブログ投稿で提示されます。見てみてください。