SQL、MySQL、または他のデータベースのようなレコードのシステムを必然的に取得/更新する他のAPIを呼び出すAPIに取り組んでいます。 SORが実行される前に、APIの3/4レイヤーが存在する場合があります。
通常、Entity FrameworkまたはADO.NETなどを介してレコードのシステムに対して関数を直接実行する場合は、リポジトリクラスを使用します。
この場合、SORと直接対話するのではなく、別のAPIを介して対話します。
このロジックはリポジトリではなくサービス内に配置する必要がありますか?
むしろ、このコードをリポジトリクラスに分離することには実際にメリットがありますか?
私の知る限り、リポジトリクラスにはビジネスロジックを含めないでください。
私にとってリポジトリの目的または主な利点は、DALを残りのコードから分離できることです。との間で交換するときSQLおよびMySQLデータベース。
他のAPIの呼び出しは、リポジトリレイヤーで行う必要があります。
サービスレイヤーは、データの取得元に関係なく、データの取得方法を気にする必要はありません。
リポジトリの仕事はデータベースと通信するのではなく、それはデータソースと相互運用するであり、システムの他の部分からこれらの詳細を抽象化することです。データを取得し、同様に重要なそのデータをソースの言語とレイアウトからサービスの言語とレイアウトに、またはその逆に変換、データベーステーブルからオブジェクト、JSONからオブジェクト、またはその他の形式に変換します。
これはビジネスロジックではなく、データロジックであり、それとは別のものです。