When working on large projects, we usually design the API(s) to implement the most requirements. Sometimes, the API might contain a lot of methods. In such cases, it is recommended to split the methods of the API into multiple classes. However, there is no rule that defines the exact threshold for the number of methods inside the API to start splitting the API class into multiple classes.
For example, a complex MyApi might be split into classes MyApi1, MyApi2, and so on. This sounds simple, but splitting into multiple APIs might also have many disadvantages. If so, you keep the implementation in MyApi, but that one will be complex to manage inside the team.
One interesting solution that we use in projects is to allow MyApi to grow, but to split the implementation into multiple files:
MyApi.cs MyApiPart1.cs MyApiPart2.cs
In Visual Studio these files look like:
To have a better structure of files in the solution explorer we group files together.
To achive this, following must be done in .csproj file.
<ItemGroup> <Content Include="MyApi.cs" /> <Content Include="MyApiPart1.cs"> <DependentUpon>MyApi.cs</DependentUpon> </Content> <Content Include="MyApiPart2.cs"> <DependentUpon>MyApi.cs</DependentUpon> </Content> </ItemGroup>