記事ディレクトリ
メイビン
Maven は、プロジェクト オブジェクト モデル (プロジェクト オブジェクト モデル、pom ファイル)、プロジェクト ライフ サイクル (コマンド)、および依存関係管理システム (座標) を含むプロジェクト管理ツールです。
Maven を使用する利点:
1. プロジェクトのモジュールを構築するのに便利で、プロジェクト構造を簡素化し、分業開発を促進し、開発効率を向上します。
2. Maven は、異なるシステムの依存関係を統一的に管理でき、依存関係を転送および継承できるため、プロジェクトのアップグレードに便利です。
3. Maven には、複数の jar パッケージを 1 つの jar パッケージにパッケージ化する maven-shade や、ソース コードのコンパイルに使用される maven-compiler-plugin など、機能拡張に便利なプラグインも多数あります。プロジェクトなどの
Maven リポジトリ
Maven ウェアハウスは、リソースを保管し、さまざまな jar パッケージを管理するために使用されます。
倉庫は次の 3 つのタイプに分類されます。
- 中央倉庫: Maven チームによって維持される世界で唯一の倉庫
- ローカル ウェアハウス: 自分のコンピュータ上のディレクトリ
- リモート倉庫: 通常、企業チームによって構築されるプライベート倉庫
Maven 座標
- groupId : 現在の Maven プロジェクトが属する組織の名前を定義する組織 ID (通常は逆のドメイン名、例: com.qjk)
- artifactId: 現在の Maven プロジェクト名を定義するプロジェクト ID (通常は、order-service、goods-service などのモジュール名)
- version : 現在のプロジェクトのバージョン番号を定義します
- パッケージ化: Maven プロジェクトをパッケージ化する方法を定義します。パッケージ化がない場合、デフォルトは jar パッケージです。
- classifier : この要素は、ビルド出力への添付ファイルを定義するために使用されます。補助コンポーネントは主コンポーネントに対応します。
Maven が依存関係管理を実行しているのに、依然として依存関係の競合が存在するのはなぜですか? 依存関係の競合を処理する手段は何ですか?
依存関係の競合の理由:
- 推移的な依存関係により、異なるバージョンの jar パッケージ間で競合が発生するため、Maven は近接性の原則を採用して長い依存関係パスを持つ jar パッケージを除外し、その結果、
ClassNotFound
このようなエラーが発生します。 - 異なる jar パッケージには同じクラスパスがあります。
jar パッケージの競合の解決策:
- Maven Helper プラグインに従って、競合する jar パッケージの分析に役立てることができます。
- Ctrl + shift + alt + n を使用して、クラスパスが配置されている jar パッケージを検索し、対応する jar パッケージを pom から除外します。
スコープの依存関係スコープについて詳しく説明する
- コンパイル: デフォルトのスコープ。実行時に有効であり、パッケージに含める必要があります。
- test: テスト プログラム内でのみ有効であり、パッケージには含まれません。
- 提供: コンパイル時に有効ですが、実行時に提供する必要はなく、パッケージには含まれません。
- ランタイム: コンパイル中には必要ありませんが、ランタイム中には有効であり、パッケージに含める必要があります。
Maven のライフサイクル
Maven のライフサイクルは、すべての Maven プロジェクトの構築プロセスを抽象化して統合することです。
このアイデアでは、最終的に次の 5 つの段階に (順番に) 焦点を当てます。
- clean: 以前のビルドで生成されたファイルを削除します。
- コンパイル: プロジェクトのソースコードをコンパイルします。
- テスト: Junit などの適切な単体テスト フレームワークをテストに使用します。
- package: コンパイルされたファイルを jar または war パッケージにパッケージ化します。
- install: プロジェクトをローカル ウェアハウスにインストールします
注: 同じライフサイクルのセット内で、後のステージが実行されると、前のステージが実行されます。
アイデアのライフサイクルの下にあるライフサイクルの特定の段階をクリックすると、対応する Maven プラグインによって実際に完了します。
Maven アドバンスト
サブモジュールの設計
モジュール設計により、開発の分業、後のプロジェクトの管理、拡張、保守、および他のプロジェクトへの既存のモジュール機能の統合が容易になります。統合するときは、対応する Maven 依存関係を導入するだけで済みます。
継承する
異なるモジュールが同じ依存関係を導入する必要がある場合があるため、モジュールのパブリック依存関係を抽出して親プロジェクトを構築でき、この依存関係が必要な他のサブモジュールは親プロジェクトの依存関係を継承するだけで済みます。
Maven プロジェクトの継承は Java の継承と似ており、多重継承は許可されていません。つまり、モジュール プロジェクトは 1 つの親プロジェクトのみを継承できます。
ヒント: パッケージ化メソッドの概要:
したがって、Maven を使用してプロジェクトの継承関係を実装するときは、pom メソッドを使用してパッケージ化する必要があります。指定されていない場合は、
ラベルを使用して、デフォルトは jar パッケージを指定します。継承関係の実装:<packaging> pom </packaging>
バージョンロック
親プロジェクトでは依存関係のバージョンが < dependencyManagement > タグで一元管理されているため、サブプロジェクトではバージョン番号を指定する必要がなく、バージョンを変更する必要がある場合は、プロジェクト内で一元的に変更するだけで済みます。親プロジェクト。
< dependency > タグは直接の依存関係であり、このタグが親プロジェクトで設定されている場合、子プロジェクトはそれを直接継承します。
< dependencyManagement > は、直接依存しない統合依存関係管理バージョンです。サブプロジェクトでこの依存関係が必要な場合は、pom ファイルに導入する必要がありますが、バージョン番号を指定する必要はありません。親プロジェクトで指定された番号が使用されます。
ただし、親プロジェクトでは、バージョン タグを一元管理するために、各依存関係のバージョン タグ内に各依存関係のバージョン番号も分散されています。Maven が提供する関数を使用できます自定义属性和引用属性
。
重合
集約の目的は、複数のモジュールを 1 つの全体に編成して、Maven のライフサイクル操作 (クリーン コンパイル テスト パッケージのインストールなど) をワンクリックで実行できるようにすることです。
Maven における継承と集約の類似点と相違点
プライベートサーバー
プライベートサーバーは社内で一元管理されるMaven依存ライブラリです。
このプロセスは Github リモート リポジトリと似ています。。。
ステップ 1: プライベート サーバー アクセス用のユーザー名とパスワードを設定します。サーバー ラベルを使用します。
ステップ 2: 構成アップロード (公開) アドレスを指定します。
ステップ 3: プライベート サーバーがダウンロードに依存するウェアハウス グループのアドレスを設定する
同時に、プライベートサーバーからのダウンロードを許可するように設定されます。(デフォルトでは、スナップショット バージョンはプライベート サーバーからダウンロードできません。)
トムキャット
Tomcat は、Web コンテナ、サーブレット コンテナとも呼ばれる軽量 Web サーバーです。Web サーバーは HTTP プロトコル操作をカプセル化し、Web プログラム開発を簡素化し、Web プロジェクトの展開に使用され、オンライン情報閲覧サービスを提供します。
サーブレット
レイヤードデカップリング
3層アーキテクチャ
単一責任の原則に基づいて、ビジネス データ アクセス、ロジック処理、応答のバックエンド機能を完了するために 3 層アーキテクチャが採用されています。
- コントローラー: フロントエンドによって送信されたリクエストを受信し、リクエストを処理し、データに応答する制御層。
- サービス: 特定のビジネス ロジックを処理するビジネス ロジック層。
- Dao: (データ アクセス オブジェクト、データ アクセス オブジェクト層)、データベースの追加、削除、チェック、変更などのデータ アクセス操作を担当します。
3層アーキテクチャの考え方によれば、フロントエンドリクエストはまずコントローラー層を通過し、リクエストを受信し、サービス層を通じて論理処理を実行します。サービス層で論理的に処理されたオブジェクトはデータオブジェクトを取得する必要があります。 Dao 層を介して、業務処理が完了すると、Controller 層がフロントエンドへのデータに応答します。
IOC (制御の反転) と DI (依存性の注入)
3 層アーキテクチャで記述されたコードによれば、中間のサービス層は上部のコントローラー層と下部の Dao 層にそれぞれ結合されます。
階層的なデカップリングを実現するために、Spring は制御の反転 (Inversion of Control、IOC) および依存性注入 (Dependency Injection、DI) テクノロジーを提供します。
制御の反転によりオブジェクトがコンテナ管理に転送され、依存関係の挿入により、オブジェクトを使用する必要がある場所にオブジェクトが挿入されます。
- 制御の反転 (IOC): オブジェクト作成の制御がプログラムから外部 (コンテナー) に移されます。
- 依存関係の注入 (DI): コンテナーは、アプリケーションが実行時に依存するリソースを提供します。
- コンテナ内で作成および管理されるオブジェクトは次のように呼ばれます。
bean
具体的な実装プロセス:
- アノテーションを使用して
@Component
、サービス層とdao層の実装クラスをIOCコンテナに渡して管理します。 - コントローラー層がサービス層の実装クラスに依存する必要がある場合、およびサービス層が dao 層の実装クラスに依存する必要がある場合は、
@Autowired
アノテーションを使用します。
IOCの詳しい説明
IOCとはオブジェクトをコンテナ管理に引き渡すことですが、実際の開発では上記で使用したアノテーションに加えて、コントローラー層、サービス層、dao層にそれぞれ対応する 、 、 などのアノテーション@Component
を使用します@Controller
。@Service
@Repository
アノテーションを見ると@Service
、アノテーションとメタアノテーションで構成されていることがわかります@Component
。つまり、コンポーネントの派生アノテーションです。
- アノテーションを使用すると、コンテナ内で Java Bean オブジェクトが宣言されます。Bean を宣言するとき、value 属性を通じて Bean の名前を指定できます。指定しない場合、デフォルトはクラス名の最初の文字の小文字です。
- 上記4つのアノテーションを使用してBeanを宣言できますが、SpringBoot統合Web開発ではBean宣言されたコントローラーのみが使用でき、
@Controller
また、アノテーションはと を@RestController
統合した複合アノテーションであるため、 のBean宣言にも使用できます。コントローラータイプのオブジェクト。@Controller
@Requestbody
Beanコンポーネントのスキャン
- 宣言された Bean の 4 つの主要なアノテーションを
@ComponentScan
有効にするには、コンポーネント スキャン アノテーションによってスキャンする必要があります。 @ComponentScan
注釈には構成は表示されませんが、実際には起動クラス宣言の注釈に含まれています@SpringBootApplication
。デフォルトのスキャンの範囲は、スタートアップ クラスが配置されているパッケージとそのサブパッケージです。
スタートアップ クラスが配置されているパッケージの外にある Bean コンポーネントをスキャンしたい場合は、スタートアップ クラスでアノテーションを使用する必要があり、パラメータはパッケージ@ComponentScan
名です。アノテーションを使用すると@ComponentScan
デフォルトのアノテーションが無効になることに注意してください。 -スタートアップ クラスが配置されているパッケージを指定します。
DIの詳しい説明
DI 依存性注入@Autowired
アノテーションは、コンテナから型に応じて対応する Bean オブジェクトを取得するもので、同じ型の Bean が複数ある場合はエラーが報告されます
。
- @Primary: 同じ型のアノテーションが複数ある場合、このアノテーションで宣言された Bean オブジェクトが最初に注入されます。
- @Qualifier: このアノテーションを @autowired アノテーションとともに使用して、Bean の名前を指定します。
- @Resource: このアノテーションを単独で使用して Bean 名を指定します。
@Autowired
アノテーションとの違い@Resource
:
@Autowired
Spring Frameworkが提供するアノテーション@Resource
ですが@Autowired
デフォルトではタイプによって注入されます@Resource
がデフォルトでは名前によって注入されます。
私の靴
- MyBatis は優れた永続層フレームワークです
- MyBatis は、ほぼすべての JDBC (Java Database Connect) コードと、パラメータを手動で設定して結果セットを取得するプロセスを回避します。
- MyBatis は、単純な XML または注釈を使用してネイティブ情報を構成およびマッピングし、インターフェースと Java エンティティ クラス [Plain Old Java Objects、通常の Java オブジェクト] をデータベース内のレコードにマッピングできます。
- MyBatis はもともと apache のオープンソース プロジェクト ibatis でしたが、2010 年にこのプロジェクトは apache から google code に移行され、MyBatis に名前変更されました。
- Mybatis 公式ドキュメント: http://www.mybatis.org/mybatis-3/zh/index.html
- GitHub : https://github.com/mybatis/mybatis-3
構成プロセス
@Mapper
アノテーションはコンテナ内のインターフェースの実装クラスを管理するため、インターフェースの実装クラスオブジェクトを利用したい場合は、実装クラスオブジェクトを宣言し、アノテーションを利用して自動的にインジェクトするだけで、@Autowired
アノテーションによって宣言されたオブジェクトMapper
。
JDBC(Javaデータベース接続)
従来の jdbc 操作には、データをフェッチするときのカプセル化、データベースへの接続の確立など、多くの反復的なコード ブロックが含まれています。Mybatis の役割は、プログラマがフレームワークに基づいてデータベースにデータを保存し、データベースからデータをフェッチできるように支援することです。
データベース接続プール
ロンボク島ツールキット
注釈を使用して@Data
エンティティ クラスの記述を簡素化します。
Mybatisの基本操作
Mybatis で SQL ステートメントを構成するには 2 つの方法があります。
- 注釈ベース
- XMLベースのマッピングファイル
消去
プリコンパイルされたSQL
- プリコンパイル済み SQL の方がパフォーマンスが優れています。たとえば、同じ SQL の場合、パラメータのみが異なります。プリコンパイル済み SQL を使用すると、SQL をキャッシュし、キャッシュを適用してパラメータを置き換え、直接実行できます。キャッシュを使用すると、SQL 構文解析チェック、SQL 最適化、SQL コンパイルをスキップできるため、パフォーマンスが向上します。
- SQL インジェクションを防止し、より安全に。SQL インジェクションは、入力データを操作して事前定義された SQL ステートメントを変更し、サーバーを攻撃するコードを実行する方法です。
SQLインジェクション攻撃の場合:
ログイン時に入力: アカウント名は任意、パスワードは'or '1' = '1'
バックグラウンドで検証する場合:
==or '1' = '1'== が常に成立していることがわかり、当然いつでもログインできます成功しました!
パラメーター プレースホルダーの使用に加えて#
、プレースホルダーも使用できます$
。違いは次のとおりです。
追加
主キーの戻り値:注釈を
使用し@Options
、useGeneratedKeys = true、主キーを id 属性に割り当てます。
改訂
お問い合わせ
データのカプセル化:
エンティティ クラスの属性名がフィールド名と一致しない場合、フィールド値をクラスの属性値に自動的にカプセル化できません。
解決策は次のとおりです。
- 解決策 1: フィールドにエイリアスを付けて、エイリアスがエンティティ クラスの属性と一致するようにします。
- 解決策 2: @Result アノテーションを使用して手動でマップおよびカプセル化する
- 解決策 3: Spring 構成ファイル (
application.properties
) で、mybatis ハンプ名の自動マッピング スイッチを有効にします。mybatis.configuration.map-underscore-to-camel-case =true
ファジー クエリでワイルドカードを使用する場合は%
、一重引用符のスプライシングを使用する必要があり、使用するワイルドカードを引用符内に含めることはできません。提供されている SQL プリコンパイル機能を#
引き続き使用するには、文字のスプライシング メソッドを使用してください。#
concat
XMLマッピングファイル
XML マッピング ファイルを使用して SQL を構成することもできます。
仕様に従って記述された XML ファイルは通常どおり検索され、その中の SQL ステートメントを実行できます。
mybatis アノテーションの使用は主に、追加、削除、変更、クエリなどの単純な機能を完了することですが、複雑な SQL 関数を実装する必要がある場合は、XML を使用して SQL ステートメントを構成することをお勧めします。
Mybatis動的SQL
ユーザー入力や外部条件の変化に応じて変化する SQL ステートメントは、動的 SQL と呼ばれます。
動的 SQL の作成は、主にいくつかのラベル ステートメントに依存します。
- < if >: 条件が真であるかどうかを判断するために使用され、条件が真である場合は test 属性を使用して条件を判断し、SQL をつなぎ合わせます。
- < where > : where 要素は、子要素にコンテンツがある場合にのみ where 句を挿入し、句の先頭にある and または or を自動的に削除します。
- < set > : 行の先頭に set キーワードを動的に挿入し、余分なカンマを削除します。(更新ステートメントで使用されます)
- <foreach>:
- コレクション: 走査するコレクション
- item: 通過した要素
- セパレータ: セパレータ
- open: トラバーサルが開始される前に結合された SQL フラグメント
- close: SQL フラグメントはトラバーサル後に結合されます。
このタグは主に、次の疲労削除の例など、バッチ操作が必要なシナリオで使用されます。
- <sql> と <include>: SQL フラグメントを大量に繰り返し使用する場合、<sql> タグを使用して高頻度に繰り返されるタグを抽出して処理し、ID 名を設定できます。 <include> タグを使用し、refid を ID 名に設定し、参照を置換します。
休息スタイルの API
Representation State Transfer、表現状態遷移、ソフトウェア アーキテクチャ スタイル。
URL を使用してリソースを見つけ、HTTP 動詞 (リクエスト メソッド) を使用して操作を説明します。
- クエリ: 取得
- 追加: 投稿
- 変更: 置く
- 削除:削除
プロパティ設定ファイル
パラメータ設定
application.properties ファイルに構成情報の属性値を設定し、@Value
Java ファイルのアノテーションを通じて外部構成ファイルの属性値を注入します。
yml設定ファイル
yml または yaml 形式の構成ファイルを使用すると、より簡潔になり、階層構造が明確になります。
構成プロパティ
挿入された構成プロパティを使用するのは@Value
面倒ですが、この手順を簡略化することはできますか?
アノテーションを通じて@ConfigurationProperties
、構成ファイル内のプロパティ値がオブジェクトに挿入されます。
依存関係は Maven に追加できます。
ケースの実装 - ログイン認証
サーバーはリクエストを受信すると、ログイン状態かどうかを確認し、ログイン状態であれば通常どおり処理し、そうでない場合はリクエストをインターセプトします。
サーバーは通常、ログイン検証機能を実現するために統合インターセプトを採用し、ログインしている場合にマークを付けます。
会話テクノロジー
クッキー
Cookie: クライアント セッション トラッキング テクノロジ、http プロトコルでサポートされるテクノロジ。ログインに成功すると、サーバーは set-cookie で応答し、ブラウザに Cookie を送信します。ブラウザは Cookie をローカルにキャッシュし、その後の要求ヘッダーに Cookie が含まれます。ログインの確認状態。
Cookie の欠点:
- モバイルアプリは利用できません
- 安全ではありません。ユーザーは Cookie を無効にすることができます
- Cookie はドメインを越えることはできません
- クロスドメインはプロトコル、IP、ポートの 3 つの次元に分かれています
セッション
Session はサーバー側のセッション追跡テクノロジであり、セッションはサーバー側に保存され、その最下層は引き続き Cookie に基づいています。
セッション追跡の原理:
ブラウザーのログイン要求は JSESSION、つまりセッション ID を提供し、サーバーは set-cookie を通じてセッション ID を設定し、それをサーバーに保存し、次に、リクエストを送信するときにブラウザがサーバーによって保存されたものと一致するかどうかで、セッションであるかどうかを判断できます。
セッションの欠点:
セッションはサーバーに保存されるため、サーバー クラスターではセッションを使用できません。
トークンテクノロジー
ブラウザが正常にログインすると、サーバーはクライアント用のトークンを生成し、クライアントはトークンを保存し、後続のリクエストで送信されます。同じセッションで情報を共有する必要がある場合、情報はトークンに保存されます。
アドバンテージ:
- トークントークンは Cookie に保存することも、クライアント側でローカルに保存することもできるため、PC およびモバイル端末をサポートします。
- クラスター環境における認証の問題を解決できます。
欠点: トークントークンは自分で実装する必要がある
JWTトークン
JWT (Json Web Token)、json ネットワーク トークンは、2 つの通信当事者間で json データ形式で情報を安全に送信するための簡潔な自己完結型形式を定義します。デジタル署名の存在により、これらのメッセージは信頼できます。
JWT トークンは主に 3 つの部分で構成され、.
次の 2 つの点で接続されています。
- ヘッダー(header)、レコードトークンタイプ、署名アルゴリズム
- ペイロード (ペイロード)、いくつかのカスタム情報、デフォルト情報を運びます。
- 署名 (署名) は、トークンの改ざんを防止し、セキュリティを確保するために、指定された秘密鍵にヘッダーとペイロードを追加し、指定された署名アルゴリズムによって計算されます。
JWTはもともとjsonですが、どうやって文字列に変換するのでしょうか?
Base64エンコードとは、いわゆるbase64エンコードとは、64文字(0-9、az、AZ、+、/)で構成されるエンコード方法です。Base64 でエンコードされたデータはすべて 64 文字の文字列に変換されます。
jwt トークンの Base64 エンコードとデコードは、次の Web サイトで実行できます:
https://jwt.io/
Java コードに基づいて JWT を生成します。
ペイロード部分はハッシュ テーブルに保存され、コンストラクター モードで構築されます。
生成された JWT は、有効期限内に秘密キーによって解析できます。
トークンの有効期限が切れたり改ざんされたりすると、トークンは間違ったものになります。
フィルター
フィルタ: いくつかの特別な機能を実現するためにリソースのリクエストをインターセプトするフィルタ。通常、フィルターはログイン検証、Unicode 処理、機密文字処理などのいくつかの一般的な操作を実行します。
インターセプトを構築する手順:
- フィルターの定義: Filter クラスを定義して Filter インターフェイスを実装し、そのすべてのメソッドを書き換えます。
- フィルターの構成: @WebFilter 注釈をフィルター クラスに追加し、インターセプト リソース パスを構成し、@ServletComponentScan をブート クラス (メイン関数が配置されている) に追加して、サーブレット コンポーネントのサポートを有効にします。
@WebFilter アノテーションに属性を追加して、urlPatterns
インターセプトされたリクエストのパスを構成します。
フィルタ実行処理の詳細説明
Filter インターフェイスでは、次の 3 つのメソッドを書き直す必要があります。
- init: 初期化、1 回のみ実行
- doFilter: リクエストをインターセプトした後に呼び出され、複数回呼び出すことができ、解放リクエストをここで実行できます
chain.doFilter()
。 - destroy: 破棄メソッドは 1 回だけ呼び出されます。
フィルターチェーン
フィルター チェーンの実行順序の優先順位は、フィルター クラス名 (文字列) の自然な順序に従います。
ログイン検証フィルタープロセス
インターセプター
インターセプターはフィルターに似たメカニズムですが、インターセプターは Spring フレームワークによって提供されます。
Java でのインターセプターの使用:
- HandlerInterceptor インターフェイスを実装するインターセプター クラスを定義し、メソッドをオーバーライドします。インターセプタは Spring フレームワークによって提供されるため、
@Component
アノテーションを直接使用してクラスをコンテナに渡して管理できます。 - インターセプターを登録します。 @Configutation アノテーションを使用して構成クラスを宣言し、
WebMvcConfigurer
この構成クラスにインターフェースを実装し、 annotation を使用して上記のインターセプター クラスを注入してAutoWired
から、 addInterceptors メソッドでインターセプター クラスにインターセプト パス モードを追加します。
インターセプターモード:
フィルターとインターセプターの違い
- インターフェイスの仕様は異なります。フィルターは Filter インターフェイスを実装し、インターセプターは HandlerInterceptor インターフェイスを実装します。
- インターセプトの範囲は異なります: フィルター フィルターはすべてのリソースをインターセプトし、インターセプターは Spring 環境内のリソースのみをインターセプトします。プロジェクトにフィルターとインターセプターの両方がある場合、フィルター フィルターが最初に実行されます。
例外処理
Spring Frameworkでは例外が発生するとレイヤー間に影響を及ぼします。例外を均一に処理するには、グローバル例外ハンドラーを使用することをお勧めします。
グローバル例外ハンドラ
@RestControllerAdvice アノテーションを使用します。
Springトランザクション管理
適用例: 部門を削除する場合、その部門の下にあるすべての従業員を同時に削除する必要があります。
実装方法:アノテーションを利用する アノテーション@Transactional
はビジネス層(Service)層のメソッド、クラス、インターフェースに配置されます。
機能: 現在のメソッドをトランザクション管理用の Spring に渡します。メソッドの実行前にトランザクションを開始します。実行が成功したら、トランザクションをサブミットします。例外が発生した場合は、トランザクションをロールバックします。
トランザクション管理のログ構成を有効にします。
先進的なビジネス
上記の場合、delete メソッドで @Transactional アノテーションを直接使用して、トランザクションを開始します。
デフォルトでは、実行時例外が発生した場合にのみ例外がロールバックされます。@Transactional で属性を指定rollbackFor
すると、発生する例外の種類を制御し、トランザクションをロールバックできます。
属性に加えてrollbackFor
、トランザクション アノテーション @Transactional では伝播動作propagation
属性も指定できます。
デフォルトのトランザクション伝播動作では、トランザクションが存在する場合は既存のトランザクションにメソッドが追加され、トランザクションが存在しない場合は新しいトランザクションが作成されます。
どうしたの?
以下の要件を考慮してください。
操作ログはトランザクションの成否に関わらず必要となるため、try-catch-finallyの最後に操作ログのメソッドを入れれば実現できます。
ただし、実際の実行処理では、トランザクションの実行が失敗してロールバックが発生した場合、finally コードブロック内の操作ログの実行メソッドもロールバックされます。
解決策は、
操作をログに挿入するメソッドのトランザクション アノテーションで、伝播モードを propagation = として指定することですPropgation.REQUEST_NEW
。
このように、ログを操作する方法は新しいトランザクションを開始し、失敗したトランザクションのロールバックの影響を受けません。
AOP (アスペクト指向プログラミング)
実際、AOP (Aspect Oriented Programming、アスペクト指向プログラミング) は、元のメソッドを拡張したり、元のメソッドを適応させたりできる特定のメソッド用のプログラミングです。
AOP アスペクト指向プログラミングは、動的プロキシ モードを通じて実現されます。
AOPのコアコンセプト
- 接続ポイント: JoinPoint、AOP によって制御できるメソッド (メソッドの実行時に関連情報が暗黙的に示されます)
- 通知: アドバイス。繰り返されるロジック、つまり共通の機能を指します (最終的にメソッドとして具現化されます)。
- Pointcut: PointCut、結合ポイントの条件に一致し、ポイントカット メソッドが実行された場合にのみアドバイスが適用されます。通常、カットイン方法に合わせてポイントカット表現が使用されます。
- アスペクト: 通知とエントリ ポイントの対応関係を記述するアスペクト (通知 + エントリ ポイント)
- ターゲット オブジェクト: ターゲット、通知が適用されるオブジェクト。
高度な AOP
通知タイプ
ポイントカット式は、アノテーションを介して@Pointcut
抽出できます。その後、必要に応じて再利用します。
通知順序
ポイントカット式
実行
戻り値、パッケージ名、クラス名、メソッド名、メソッド パラメータ、およびメソッドのその他の情報に従って照合し、実行
エントリ ポイント式のワイルドカードを使用します。
注釈
アノテーションは、特定のアノテーションで識別されるメソッドを照合するために使用されます。
アノテーションを定義する:
通知が必要なメソッドにこのアノテーションを追加します。
ジャンクション
実際の実行メソッドに関する情報を取得するために使用されます。
春
設定の優先順位
スピン属性の設定:
Bean管理
ビーンを入手
実際の手順:
- IOC コンテナ オブジェクトの applicationContext は、(@Autowired アノテーションを使用して) インジェクションによって取得されます。
- applicationContext オブジェクトによって提供される API が Bean を取得します。
Bean スコープ
デフォルトのスコープによって作成され、取得された Bean オブジェクトはシングルトンであり、 @Scope アノテーションを使用してスコープを構成できます。
サードパーティ Bean
サードパーティの依存関係によって Bean が生成されることもあります。@Bean アノテーションを使用する必要があります。
Spring Boot の原理
SpringBoot は Spring Framework を簡素化し、主な原則は、最下層が開始時の依存関係と自動構成を提供することです。
依存関係を開始する原則は、Maven の依存関係の転送です。
自動構成の原理
Spring プロジェクトのスタートアップ クラスは、デフォルトでスタートアップ クラスにアノテーションを追加し@ComponentScan
、スタートアップ クラスが配置されているパッケージの下のアノテーションをスキャンしComponent
、アノテーションを持つクラスを IOC コンテナに追加します。
次に、サードパーティ ライブラリの構成クラスが自動アセンブリを実現したい場合、最初の解決策は、アノテーション@ComponentScan
コンポーネントのスキャンを使用することです。
ただし、このソリューションの欠点は、アノテーションが宣言されるたびに@ComponentScan
、パッケージ内のすべてのファイルをスキャンする必要があり、使用が面倒でパフォーマンスが低いことです。
オプション 2: @Import アノテーションを使用します。
- @Import は、通常のクラスまたは @Configuration アノテーションが付けられた構成クラスで宣言できます。IOC コンテナに直接インポートできます。
- インポート クラスを作成し、ImportSelecter インターフェイスを実装します。IOC コンテナにインポートする必要がある完全なクラス名の文字列配列を返すように、このインターフェイスによって提供されるメソッドを書き直す必要があります。
- 上記の方法では、どのクラスを IOC コンテナにインポートする必要があるかを正確に知る必要があります。
@EnableXxxx
実際、サードパーティの依存関係は、どのクラスを IOC コンテナにインポートする必要があるのかを最も明確に示しているため、サードパーティの依存関係は、アノテーションをカプセル化するアノテーション を提供できます@Import
。これを使用するときは、スタートアップ クラスにアノテーションを追加するだけで済みます@EnableXxxx
。
@SpringBootConfiguration
@SpringBootConfiguration アノテーション:
- @ComponentScan アノテーションが統合されているため、スタートアップ クラスが存在するパッケージおよびサブパッケージ内の @Component アノテーションを含むすべてのクラスがスキャンされます。
- @Configuration アノテーションを統合すると、スタートアップ クラスでサードパーティの依存関係宣言用に @Bean を構成することもできます。これも構成アノテーションです。
- 最も重要なこと: これには、Spring-boot-autoconfigure パッケージにある 2 つのファイルを文字列リストの形式で返すことを実装する EnableAutoConfiguration アノテーションが含まれており、これら 2 つのファイル内のレコードを IOC に完全にインポートする必要があります。コンテナのクラスの修飾クラス名。
@条件付き
特定の条件に従って判断され、特定の条件が満たされた場合にのみ、Bean オブジェクトが Spring の IOC コンテナに登録されます。
- ConditionalOnClass: 環境内にバイトコード ファイルが存在するかどうかを確認し、Bean を IOC コンテナに追加します。
- ConditionalOnMissingBean: Bean が環境内に存在するかどうかを判断し、存在しない場合、Bean は IOC コンテナーに登録されます。通常、デフォルトの Bean 宣言に使用されます。
- ConditionalOnProperty: 設定ファイルに対応するプロパティと値があるかどうかに応じて、Bean が IOC コンテナに登録されます。
カスタムスターター
命名規則:
Spring-boot-starter-function は、Spring によって公式に提供される起動依存パッケージの名前です。
他のテクノロジーによって提供される起動依存パッケージ名では、関数名が最初に表示されます: function-spring-boot-starter
カスタム スターターは、起動依存関係と自動構成という 2 つのパッケージを完了する必要があります。これらはそれぞれ、依存関係管理機能と自動構成機能を完了します。
ケース: Alibaba Cloud OSS ランチャーのカスタマイズ
ステップ 1: Enabler と Autoconfig という 2 つのモジュールを作成します。
ランチャーは自動構成に依存しています。
ステップ 2: Alibaba Cloud OSS ロジック関数の実装を完了します。
まず、spring-web および Alibaba Cloud oss の依存関係を含む依存関係をインポートします。
使用時に構成情報を渡す必要がある AliOSSUtills クラスの記述を実現します。
構成情報もクラスオブジェクトをカスタマイズする必要があり、その属性値は、@ConfigurationProperties
アノテーションを通じて構成ファイル内の「aliyun.oss」というプレフィックスが付いたオブジェクト属性を参照します。
ステップ 3: 自動構成クラスを構築します。
@EnableConfigurationProperties アノテーションを使用して、Spring の自動構成パスをたどり、構成ファイルを作成し、コンテナーに登録する必要があるクラス名をリストします。 ステップ 4: テストの使用 テスト モジュールは、スターター モジュールの依存関係を導入するだけで済み
ます
。今。
設定ファイルで、Alibaba Cloud oss の設定プロパティを設定します。
これにより、使用時に直接挿入できるようになります。
要約する