Support generating multiple files

[christianhelle]

Feature description
Add support for generating multiple files.

For example, separate files for the refit interfaces, contracts, and dependency injection setup.

Discussed in #385

[berkslv]

This will be a great feature, because clean architecture enforce you to separate external service implementation in infrastructure layer and their models in domain layer. similiar approach is used by ef core scaffold command, maybe we can take this as an example for our approach.

Scaffold-DbContext "Data Source=.;User ID=SA;Password=Passw0rd;Database=Sample;Connect Timeout=30;Trust Server Certificate=True;Application Intent=ReadWrite;Multi Subnet Failover=False" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Entities -Force -NoOnConfiguring -Context SampleDbContext -ContextDir ..\Sample.Infrastructure\Persistence\ -ContextNamespace Sample.Infrastructure.Persistence -Project Sample.Domain

I think we could use --contracts-output, --contracts-namespace to generate contracts and the contracts namespace should be added to generated client file as a using statement.

For now, --contract-only option can be used as refitter ./openapi.json --output ./GeneratedContracts.cs --contract-only. But this approach require you to execute two seperate refitter command to generate clients and generate contracts

[christianhelle]

@berkslv Sorry for the late reply, it took longer than expected to get out of vacation mode 😄

I think we could use --contracts-output, --contracts-namespace to generate contracts and the contracts namespace should be added to generated client file as a using statement.

For now, --contract-only option can be used as refitter ./openapi.json --output ./GeneratedContracts.cs --contract-only. But this approach require you to execute two seperate refitter command to generate clients and generate contracts

I can see the value in splitting the contracts and interfaces into multiple files in multiple locations on disk across multiple .NET projects when the system with these files also "owns" the contracts. I wouldn't care too much about splitting files or types across multiple .NET projects when the system that generates them uses another system's OpenAPI specifications as that would be the equivalent of adding a package reference to that other system's client library (like an SDK)

That said, it's not technically hard to implement, so I'll think about it. I have already made quite some progress with splitting the generated code into multiple files. Once I get those changes in maybe I'll re-visit the idea of having options to specify the output file/location for each generated file