5

私がプロとしてのキャリアを積むにつれて、命名規則は非常に重要だと考えています。LibraryController私は、人々がコントローラー、、サービスLibraryService、、およびプロバイダーを投げ回し、LibraryProviderそれらをいくらか交換可能に使用していることに気づきました。一方と他方を使用する特定の理由はありますか？

より具体的な定義を持つウェブサイトがあれば、それは素晴らしいことです。

4

4 に答える 4

4

Java Spring、Spring Boot、および.NET では、次のようになります。

  • Repository: データベースにデータを保持し、SQL クエリを実行します。
  • Service: ほとんどのビジネス ロジックを含む
  • Controller: できるだけ少ないロジックを含む REST エンドポイントを定義します。

概念的には、これはWHAT (機能) がHOW (技術) から可能な限り分離されていることを意味します。サービスは、技術的に中立を維持しようとします。対照的に、コントローラは通信のための外部コントラクトを定義したいだけです。最後に、リポジトリはデータベースへのアクセスを容易にすることだけを望んでいます。

このようにコードを整理することで、ビジネス ロジックを短く、クリーンで保守しやすくします。残念ながら、それらを分離しておくことは必ずしも容易ではありません。たとえば、デコレータ/アノテーションの形でメタデータを使用してオブジェクトを汚したり、充実させたりするのは魅力的です。(例: データベースの列名とデータ型)。

一部の開発者は、これに害を及ぼさず、それを回避します。また、オブジェクトを厳密に分離し、複数のオブジェクト セットを定義するものもあります。

Mappers複数のオブジェクトがあるということは、あるタイプのオブジェクトを別のタイプに変換する必要があることを意味します。フレームワークによっては、これを行うことができます (例: MapStruct)。

厳格さは常に良いことだと主張するのは簡単ですが、それはあなたを遅くする可能性があります. バランスをとって大丈夫です。

Node.jsでは、コントローラーとサービスの概念は同じです。ただし、この用語Repositoryはあまり使用されません。代わりに、彼らはそれを と呼ぶか、Provider単にRepositories一種の として一般化することがありServiceます。

NestJSはこれについてより強い意見を持っています (これは良いことかもしれません)。NestJS (Node.js フレームワーク) の命名規則は、もちろんまったく異なる種類のフレームワーク (フロントエンド) である Angular の命名規則の影響を強く受けています。

(完全を期すために、Angular では、 aProviderは実際には依存関係として注入できるものにすぎません。ほとんどのプロバイダーは ですがServices、必ずしもそうとは限りません。( aGuardまたは a でさえある可能性がありますModule。Module ) PS: とにかく、この用語の使用法は、「ES6 モジュール」も存在するためModule、少し混乱しますが、これはまったく別のものです。 )

ES6 および最新バージョンの JavaScript (typescript を含む) は、オブジェクトの (分解) 構築に関して非常に強力です。これにより、マッパーは不要になります。

そうは言っても、ほとんどの Node.js と Angular の開発者は、最近は typescript を使用することを好みます。typescript は、型の定義に関しては Java や C# よりも多くの機能を備えています。

したがって、これらすべてのフレームワークは互いに影響し合っています。そして、彼らはほぼ全員、コントローラーとサービスが何であるかについて同意しています。意味が異なるのは、主にリポジトリとプロバイダーの単語です。それは本当に慣習の問題です。フレームワークに規則がある場合は、それに従います。ない場合は、自分で選択してください。

于 2020-12-09T20:53:12.073 に答える
0

これにつまずいた古い開発者。私の意見と、過去 20 年間に使用された方法は、言語によって異なることを示していますが、Java C# の群集は主に次のように使用しています。

サービスは、ビジネス ロジックを処理し、ドメイン オブジェクトを処理します。サービスはコントローラーとその他のサービスにあります。

リポジトリはビジネス ロジックを処理しませんが、代わりにドメイン オブジェクトのプールのように機能します (それらを検索または永続化するためのヘルパー メソッドを使用します。サービスにはリポジトリが含まれることがよくあります。リポジトリには多くの場合、コンテキストが含まれ、インフラストラクチャ型のデータからドメイン型のデータへのマッピングを担当します)。定義がばらばらになっている場合. コントローラーには、crud エンドポイントのリポジトリも含まれていることがよくあります。

コンテキストは、ドメインが所有するインフラストラクチャを処理します。ほとんどの場合、これはデータベースですが、コンテキストとは、このデータに触れるものはすべて、このコンテキスト (内) を通じて行われることを意味します。コンテキストは、インフラストラクチャ形式のデータを返します。多くの場合、リポジトリにはコンテキストが含まれています。サービス内の直接のコンテキストが適切な場合があります。コントローラーのコンテキストは難しいです。

プロバイダーは、他のアプリが所有するインフラストラクチャへのアクセスを提供します。ほとんどの場合、これらは REST API ですが、他の誰かからデータを読み取ったり、他の誰かにデータをプッシュしたりする kafka ストリームまたは rpc クラスにすることもできます。一部のドメイン オブジェクト フィールドの信頼できる情報源が変更された場合、おそらくリポジトリ内のコンテキストの横にプロバイダーが表示され、リポジトリは残りのコードをその変更から隔離します。多くの場合、rpc 機能を提供するプロバイダーはサービスに含まれています。マイクロ サービスやゲートウェイ、または垂直スライス アーキテクチャでは、プロバイダーがコントローラーに直接表示されることがあります。

先輩の意見ですが参考になれば幸いです。

于 2021-11-24T02:01:42.327 に答える