-
-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TResource type differing from IQueryable type. #794
Comments
Projecting into a different storage data shape in general is a hard problem to solve. EF Core provides some mechanisms for indirection, such as alternative table/column names and table inheritance. This may get you a long way, combined with using calculated properties on resources which depend on non-exposed properties that are mapped in EF Core. Perhaps some examples of what you're trying to achieve help to better understand your needs. Adding a generic parameter to the service to query on a different data structure clashes with applying query string parameters, because they expect TResource to be applied on. And injecting such services sounds like a challenge, as the storage type is unknown to JADNC. In any case, the repository and service interfaces are about to change substantially in #792, which provides stricter separation between service and repository by using an intermediate constraints model. The service contains no more usage of IQueryable, the repository only internally. This allows you to pick any storage format and/or technology, but it likely involves some work depending on what you're trying to achieve. There's also some EF Core support in AutoMapper in case it helps. |
Yeah. Okay. Removing the exposure of I'm thinking about non-EF stuff... like CosmosDB, etc. Where the class used for querying the data source isn't the same shape as the resource being returned. |
In case it helps. there's support in EF Core for CosmosDB. Once #792 is merged, you should be able to implement your own repository and accept In the future I may be working on implementing parts of that to send queries to Elasticsearch instead of SQL. Closing this out, as the question seems answered. |
I am not using Entity Framework, since I do not want to couple my resource model to the underlying data model. As such, I am implementing a custom
IResourceRepository<TResource>
.The
IResourceRepository
essentially allows you to compose up anIQueryable
, applying filters, and sorts, to the underlying data source. Each method takes an IQueryable, and then returns an IQueryable. However: I do not intend to actually use this IQueryable as the final result. I would like theToListAsync
method to have a different return type.The
IQueryable
can be used to compose up EF Core operations, like filters, or whatever, but then the final transformation of the data into aResource
should allow me to transform theIQueryable
. Essentially, the IQueryable should not necessarily be theTResource
type. I think it would make more sense if the interface was insteadIResourceRepository<TResource, TQueryable>
. That way each of the composition methods (Get
,Include
, etc) would shape the IQueryable, but the finalToListAsync
method could transform that into the actual resource type.Thoughts?
The text was updated successfully, but these errors were encountered: