(Sub)namespace per DbContext
Closed this issue · 4 comments
If configuring JADNC with multiple DbContexts like in the example MultiDbContextExample I think it would make sense to be able to scope resources for respective DbContext under a namespace that lives under the optional namespace in IJsonApiOptions.
This is already possible, if you want to. See https://github.com/json-api-dotnet/JsonApiDotNetCore/blob/267876985c5457ed1f55514d14c5ea27ade1e916/docs/usage/routing.md#customized-routes.
But I don't think the details of which internal database is used should leak out to the public API surface. It complicates future refactorings when such a strong dependency is introduced.
I assume disabling the built in routing conventions and just setting a route will have some consequences that might or might not be acceptable, and a full custom routing convention is a fairly complex affair it seems.
Multiple DbContexts can be to the same database? It can makes sens to me to use multiple DbContext for different data model domains that do not have direct relationships. For that scenario doesn't it make sense to be able to namespace those domains in the API?
I assume disabling the built in routing conventions and just setting a route will have some consequences that might or might not be acceptable, and a full custom routing convention is a fairly complex affair it seems.
Not really. The only place where options.Namespace is read is here, to override the routing template here. This is basically the same as when [Route] is used directly, such as in this test. Everything else that depends on routes (such as mapping controller action methods and rendered links) is handled by ASP.NET itself.
Multiple DbContexts can be to the same database? It can makes sens to me to use multiple DbContext for different data model domains that do not have direct relationships. For that scenario doesn't it make sense to be able to namespace those domains in the API?
What would be the advantage of using multiple DbContext types for the same database in a single API? It complicates things such as database migrations and reduces the capabilities of EF Core to cache queries, precompiled selectors, etc.
Today, I would never have introduced options.Namespace. Because it can be accomplished directly in ASP.NET by using PathBase (see https://andrewlock.net/understanding-pathbase-in-aspnetcore/). I suspect it was introduced for conventional routing long ago, so before endpoint routing (using attributes) became the standard in ASP.NET.
If you really want this, it shouldn't be hard to register your own IApplicationModelConvention and override route templates from code using any custom pattern you desire.
Thanks @bkoelman, as you suggest I will try to use the tools available already. Closing.