クラスベースの環境での懸念/コードの分離（例としてC＃が使用されています）

Question

クラスベースの言語でコードを分離するのがベストプラクティスであると私は常に考えてきました。例として、私は私のWeb APIとのAPIのやりとりを扱うプロジェクトを作った。私は、正しい選択肢があるか、別の提案があるかを知りたい。

例1

プロジェクトファイル

• Api.cs
• データ型
  • Anime.cs
  • Episode.cs

Api.cs

public class Api 
{ 
    public static async Task<List<Anime>> GetAnimesByKeyword(string keyword) 
    { 
     // Execute api request to server 
     return result; 
    } 

    public static async Task<List<Episode>> GetEpisodesByAnime(Anime anime) 
    { 
     // Execute api request to server 
     return result; 
    } 

} 

データ型 - > Anime.cs

public class Anime 
{ 
    public string Name { get; set; } 
    public string Summary { get; set; } 
    // Other properties 
} 

データ型 - > Episode.cs

public class Episode 
{ 
    public string Name { get; set; } 
    public Date ReleaseDate { get; set; } 
    // Other properties 
} 

または実施例2つの

プロジェクトファイル

• Api.cs
• データ型
  • Anime.cs
  • Episode.cs

Api.cs

public class Api 
{ 
    // Nothing for now 
} 

データ型 - > Anime.cs

public class Anime 
{ 
    public static async Task<Anime> GetById(int id) 
    { 
     return result; 
    } 

    public string Name { get; set; } 
    public string Summary { get; set; } 
    // Other properties 
} 

データ型 - > Episode.cs

public class Episode 
{ 
    public static async Task<List<Episode>> GetEpisodesByAnime(Anime anime) 
    { 
     return result; 
    } 

    public string Name { get; set; } 
    public Date ReleaseDate { get; set; } 
    // Other properties 
} 

これら2の何がコードを構成する好ましい方法である、またはこれを行うには良い方法があります。それは重要ではないように見えるかもしれませんが、それは私にとって重要です。

私を助けてくれてありがとう！

Answer 1

一般に、Single Responsibility Principleに従ってください。実際には、これは、外部サービスまたはデータベースからのロードのように機能する、データのみの複雑なサービスクラスである単純なオブジェクトを持つことを意味します。

2つ目の例では、懸念が混在し、これら2つのクラスを緊密に結びつけています（Episodeは現在Animeに依存しています）。どのローディングメソッドを置くクラスを決定するのが難しいかを見ることもできます：anime.GetEpisodes()またはEpisode.GetEpisodesByAnime()？オブジェクトグラフがより複雑になるにつれ、これはエスカレートします。

後でエンティティに対して別のデータ転送オブジェクトが必要な場合があります。単純なデータのみのオブジェクトを持つと、これらを簡単に追加でき、Automapperを使用して変換することができます。

ただし、（最初の例では）staticメソッドを使用しないでください。サービスクラスをテストするのが難しくなるからです。 1つのサービスは別のサービス（依存性注入を使用）に依存し、それぞれを静的メソッドを必要としたくないと孤立してテストすることができます。