Multiple API Controllers

[robertmclaws]

Need to double-check the regression where you can't have more than one API/Model in the container. Currently, having a second API pulls the first DBContext from the Container.

[jspuij]

Internal notes / todo:

• ApiBase needs to be per route.
• ApiConfiguration needs to be part of the API again.
• PropertyBag needs to be per Api again.
• ModelBuilder is a single one and fetched through the interface.
• ModelMapper is a single one and fetcher through the interface.
• RestierQueryExecutorOptions is used as data storage in between requests using the container.
• DbContext is pulled as DbContext.
• RestierModelExtender maintains state.
• ODataValidationSettings will be shared.

[robertmclaws]

Let's talk through these, but they're going to need to be done off the Main branch first, and not your .NET Core fork.

• First thing to do would be to identify if the PropertyBag is even used. There is no documented purpose for its existence AFAIK and should be removed from the codebase.
• Second is to determine if the current incarnation of ApiConfiguration is even necessary.

Seems like some of these things could be fixed if you registered a per route configuration class that mapped the route name to the Api and DbContext types. Then the model stuff could come off the the specific ApiBase instance instead of the current structure, and you would pull the Config instance out of the DI container to find the specific instance type to grab.

Also, would like to know more about the per-route DI container in OData, and if that's per named route or per generated route.