Refactor the whole project

Short summary (3-5 sentences) describing the issue.

Recently, I got a lot of requirements, for example

1. I don't want to expand on certain element
2. I don't need this operation
3. I need this ...
4. etc..

Yes, we can meet all of these by modifying the codes, by adding settings, etc.
However, i'd think maybe it's time to refactor it in the next major release.

Design

I'd like to use the Dependency Injection to allow customer to customize the converting process.

We need figure out the working flow from OData to OpenAPI. The process steps are certain, at each step, we can create a service to work on it.

Services

We need figure out the services used during converting.
for example:

1. we should have a OData path provider service
2. we should have a OpenApi path generator service
3. We should have a convert engine

Extension methods

I think we need

public static IServiceCollection UseOpenApiOData(IServiceCollection services)
{
        services.AddSingleton<IOpenApiODataConverter>(); // converter or generator
        services.AddSingleton<IODataPathProvider>();
        services.AddSingleton<IODataOpenApiPathHandler>();
        services.AddSingleton<IODataOpenApiOperationHandler>();
.....
        service.AddSingleton<ODataOpenApiOptions>();
        return services;
}

Usage

1. you can create the OpenApiODataConverter instance (normal way)
2. you can retrieve it from service provider.

IServiceCollection services= new ServiceCollection();
services.UserOpenApiOData();
IServiceProvider sp = services.CreateServiceProvider();
IOpenApiODataConverter converter = sp.GetService<IOpenApiODataConverter>();
...

Advantage

1. It can be used in the ASP.NET Core pipeline, for example we can create a middleware to generate the OpenAPI description for a OData service.

2. It can support to customize the converting. For example, we can replace a certain service using customized service.

Es werden keine Quelldateien oder Tests genannt. Beginnen Sie damit, den OData-to-OpenAPI-Konvertierungsablauf nachzuverfolgen und den vorgeschlagenen IOpenApiODataConverter, IODataPathProvider, die path- und operation-Handler sowie das Registrierungsbeispiel für UseOpenApiOData zu überprüfen. Als abgeschlossen gilt die Aufgabe, wenn eine abgestimmte Service-Grenze und ein Dependency-Injection-Design vorhanden sind, die eine angepasste Konvertierung unterstützen.