VUE3.0 をすぐに始める方法:
Nest.js は Nodejs のバックエンド フレームワークであり、アーキテクチャ上の問題を解決するために Express およびその他の http プラットフォームをカプセル化します。 MVC、IOC、AOP、および Express にはないその他のアーキテクチャ機能が提供され、コードの保守と拡張が容易になります。
ここでの MVC、IOC、AOP とは何を意味しますか?それらを個別に見てみましょう:
MVC は Model View Controller の略称です。 MVC アーキテクチャでは、リクエストはまずコントローラーに送信され、コントローラーはモデル層のサービスをディスパッチしてビジネス ロジックを完成させてから、対応するビューを返します。
Nest.js は、コントローラーを宣言するための @Controller デコレーターを提供します。
サービスは @Injectable デコレーターを使用して宣言されます。
@Controller および @Injectable デコレーターを通じて宣言されたクラスは Nest.js によってスキャンされ、対応するオブジェクトが作成されてコンテナーに追加されます。これらのオブジェクトはすべて、コンストラクターで宣言された依存関係、つまり DI (依存関係) に従って自動的に挿入されます。 inject) )、この考え方は IOC (Inverse Of Control) と呼ばれます。
IOC アーキテクチャの利点は、オブジェクトを手動で作成し、依存関係に基づいてさまざまなオブジェクトのコンストラクターに渡す必要がなく、すべてが自動的にスキャン、作成、注入されることです。
さらに、Nest.js は、アスペクト指向プログラミングの機能である AOP (Aspect Oriented Programming) の機能も提供します。
AOP とはどういう意味ですか?アスペクト指向プログラミングとは何ですか?
リクエストは、コントローラー、サービス、リポジトリ (データベース アクセス) のロジックを通過します。
この通話リンクに一般的なロジックを追加したい場合、どのように追加すればよいでしょうか?ロギング、権限制御、例外処理など。
簡単に考えられるのは、コントローラー層のコードを直接変換して、このロジックを追加することです。これは機能しますが、これらの一般的なロジックがビジネス ロジックに侵入するため、エレガントではありません。これらのビジネス ロジックにログや権限などを透過的に追加できますか?
コントローラーを呼び出す前後に共通ロジックを実行するステージを追加することはできますか?
例えば：
このような水平展開点をアスペクトと呼び、透過的にアスペクトロジックを追加するプログラミング手法をAOP(アスペクト指向プログラミング)と呼びます。
AOP の利点は、一部の一般的なロジックをアスペクトに分離し、ビジネス ロジックを純粋に保つことができることです。このようにして、アスペクト ロジックを再利用し、動的に追加および削除できます。
実際、Express のミドルウェアのオニオン モデルも実装です。外側のレイヤーを透明にラップしてロジックを追加すると、内側のレイヤーが認識されなくなるためです。
Nest.js には AOP を実装する方法がさらにあり、Middleware、Guard、Pipe、Inteceptor、ExceptionFilter: の合計 5 つがあり、
Nest.js は Express をベースにしており、当然ミドルウェアを使用できますが、さらに細分化されています。 、グローバル ミドルウェアとルーティング ミドルウェアに分かれています。
グローバル ミドルウェアは、リクエストの前後にいくつかの処理ロジックが追加されます。
ルーティング ミドルウェアは特定のルート用であり、範囲は狭いです。
この概念は Express を直接継承しており、より理解しやすくなっています。
Guard などの Nest.js の拡張概念をいくつか見てみましょう
。Guard はルーティング ガードを意味し、コントローラーを呼び出す前に権限を決定し、解放するかどうかを決定するために true または false を返すために使用できます。
ガードの作成方法は次のとおりです。
Guard は、CanActivate インターフェイスと canActive メソッドを実装する必要があります。要求された情報をコンテキストから取得し、true または false を返す前に権限の検証やその他の処理を実行できます。
@Injectable デコレータを介して IOC コンテナに追加し、コントローラで有効にします。
コントローラー自体を変更する必要はありませんが、許可判定のロジックが透過的に追加されるのは、AOP アーキテクチャの利点です。
また、ミドルウェアがグローバル レベルとルート レベルをサポートしているのと同じように、Guard もグローバルに有効にすることができます。
Guard はルーティングのアクセス制御ロジックを抽象化できますが、リクエストと応答を変更することはできません。このロジックではインターセプターを使用できます
。とは、ターゲット コントローラー メソッドの前後にロジックを追加できます。
インテセプターの作成方法は次のとおりです。
インターセプターは NestInterceptor インターフェイスと intercept メソッドを実装する必要があります。 next.handle() を呼び出すと、その前後に処理ロジックを追加できます。
コントローラーの前後の処理ロジックは非同期である場合があります。 Nest.js は rxjs を通じてそれらを整理するため、rxjs のさまざまな演算子を使用できます。
インターセプターは、特定のコントローラーにのみ影響する各ルートの個別の有効化をサポートします。また、すべてのコントローラーに影響するグローバルな有効化もサポートします。
ルートの権限制御や対象のController前後の処理に加え、パラメータの処理も共通ロジックなので、Nest.jsでは対応する部分、つまりPipe:
Pipe はパイプを意味し、パラメータの検証と変換を行うために使用されます。
パイプの作成方法は以下の通りです。
Pipe は、形式や型が正しいかどうかなど、受信パラメータ値のパラメータ検証を実行できる PipeTransform インターフェイスと変換メソッドを実装する必要があります。変換を実行し、変換された値を返すこともできます。
8 つの組み込みパイプがあり、その意味は名前からわかります。
ValidationPipeParseIntPipeParseBoolPipeParseArrayPipeParseUUIDPipeDefaultValuePipeParseEnumPipeParseFloatPipe同様に、Pipe は特定のルートでのみ有効にすることも、すべてのルートで有効にすることもできます。
パイプ、ガード、インターセプター、または最終的に呼び出されるコントローラーのいずれであっても、プロセス中にいくつかの例外がスローされる可能性があります。特定の例外に応答するにはどうすればよいですか?
例外と応答のこのマッピングも、Nest.js がサポートする ExceptionFilter を提供します。
は、スローされた例外を処理し、対応する応答を返すことができます。
ExceptionFilter の作成形式は次のとおりです。
まず、例外をインターセプトするために ExceptionFilter インターフェイスと catch メソッドを実装する必要があります。ただし、例外をインターセプトした後、対応する例外で応答することができます。ユーザーにとってよりフレンドリーなプロンプトが表示されます。
もちろん、すべての例外が処理されるわけではありません。HttpException を継承する例外のみが ExceptionFilter によって処理されます。Nest.js には、次のような
UnprocessableExceptionRequestTimeoutExceptionServiceUnavailableExceptionPayloadTooLargeExceptionForbiddenExceptionNotAcceptableExceptionNotFoundExceptionGoneExceptionConflictExceptionUnauthorizedExceptionGatewayTimeoutExceptionNotImplementedExceptionBadRequestExceptionBadGatewayExceptionUnsupportedMediaTypeExceptionInternalServerErrorExceptionもちろん、自分で拡張することもできます。
Nest.js はこのように例外とレスポンスの対応を実現しており、コード内で別の HttpException を投げていれば対応するレスポンスが返ってくるのでとても便利です。
同様に、ExceptionFilter はグローバルに有効にするか、特定のルートに有効にするかを選択することもできます
。
グローバル：
Nest.js が提供する AOP メカニズムは理解しましたが、それらの順序関係はどのようなものでしょうか?
いくつかの AOP メカニズム (ミドルウェア、ガード、パイプ、インターセプター、例外フィルター)
しかし、それらの間にはどのような順序関係があるのでしょうか?
呼び出し関係はソースコードに依存します。
対応するソースコードは次のとおりです。
明らかに、このルートに入ると、許可があるかどうかなどを判断するために Guard が最初に呼び出されます。許可がない場合は、ここで例外がスローされます。
スローされた HttpException は ExceptionFilter によって処理されます。
許可がある場合、インターセプターが呼び出されます。インターセプターはチェーンを編成し、1 つずつ呼び出し、最後にコントローラー メソッドを呼び出します。
コントローラー メソッドを呼び出す前に、パイプを使用してパラメーターを処理します。
各パラメータは次のように変換されます。
ExceptionFilter の呼び出しタイミングは、例外を処理してから応答するという考え方が容易です。
Expressではミドルウェアは概念であり、Nest.jsはそれを継承するだけで、最外層で呼び出されます。
これは、これらの AOP メカニズムの呼び出しシーケンスです。これらを整理すると、Nest.js を十分に理解できるようになります。
Nest.js は、Express http プラットフォームに基づいてカプセル化されており、MVC、IOC、AOP などのアーキテクチャのアイデアを適用しています。
MVC は、モデル コントローラーとビュー コントローラーの分割部分であり、リクエストは最初にコントローラーを通過し、次にモデル層のサービスとリポジトリを呼び出してビジネス ロジックを完成させ、最後に対応するビューを返します。
IOC とは、Nest.js が @Controller および @Injectable デコレータを使用してクラスを自動的にスキャンし、それらのオブジェクトを作成し、依存関係に基づいて依存するオブジェクトを自動的に挿入することで、オブジェクトを手動で作成して組み立てる手間を省くことを意味します。
AOP は一般的なロジックを抽出し、アスペクトを通じて特定の場所に追加し、アスペクト ロジックを動的に追加および削除できます。
Nest.js の Middleware、Guard、Interceptor、Pipe、ExceptionFileter はすべて AOP のアイデアの実装であり、これらはすべて特定のルートまたはすべてのルートに柔軟に適用できます。
ミドルウェアは Express の概念であり、特定のルートに到達した後、最初に Guard が呼び出され、そのルートにアクセスが許可されているかどうかを判断します。インターセプターが呼び出され、いくつかのロジックを前後に展開し、ターゲットのコントローラーに到達する前にパイプを呼び出してパラメーターを検証および変換します。すべての HttpException 例外は ExceptionFilter によって処理され、異なる応答を返します。
Nest.js は、この AOP アーキテクチャを使用して、疎結合で保守と拡張が容易なアーキテクチャを実現します。
AOP アーキテクチャのメリットを感じたことはありますか?