Do we support IQueryable to reliable collection?
Something like:
Task>IQueryable>InventoryItemView>> GetCustomerInventoryAsync(CancellationToken ct)
No. Reliable collections do not support IQueryable today.
Related
I understand how IEnumerable and IQueryable works. I just cannot imagine a situation where IEnumerable would be needed in entity framework when working with SQL database. I wonder if I can just discard IEnumerable in EF. Can you provide any useful example that shows IEnumerable could be more useful than IQueryable?
There are three situations that come to mind.
When EF cannot convert your query into a correct SQL statement - so you need to bring the results into memory to complete the computation.
When you need to perform operations that involve operators that do not convert to SQL.
When SQL server is slower at producing the computation than an in-memory calculation. Many times I have found that pulling all the data into memory is quicker than letting SQL to do it.
Provided a data source (as IQueryable) can be queried, then yes, use IQueryable - though you shouldn't be creating IQueryable instances or implementing it yourself, that's what EF is for. You will still need to use IEnumerable as method parameters or return types if you're using EF with external data-sources or other data that isn't queryable itself, such as JOINing an EF table with non-EF data.
For example, you'd have a return type as IEnumerable<T> if the data you're returning isn't queryable because you called AsEnumerable or ToList but you don't want to reveal implementation details - but I'd then prefer IReadOnlyList<T> in that case.
Link:
My repositories always returns IQueryable. The reason for this is that
IQueryable is not dependent on EF whereas ObjectQuery is. So if I want
my other layers to be persistance ignorant I don't want to introduce
dependency on ObjectQuery.
a) I assume reason why repositories ( implemented using EF ) should return IQueryable instead of ObjectQuery is because other ORMs also use queries which return IQueryable, and by having repositories return IQueryable we can easily switch between EF and other ORMs, without having to change the public interface of a repository?
b) Besides EF and NHibernate, are there any other ORMs that also have queries which return IQueryable?
Thank you
You should return IQueryable because that's the lingua franca of expression trees. If it's not IQueryable, it's either some other thing that understands Expression, or its some horrible custom language which gives you a greatly inferior programming experience to
var resultsINeed = getQueryable().Where(expression1).Select(expression2);
And if it understands the Expression example here, then it might as well just be IQueryable, because that's the whole point of IQueryable - to be that general abstraction, that everybody can reuse in their interfaces.
In-memory query performed by DBSet<T>.Local will also return newly added entities that haven't yet been saved to the database. Is there some functionality that would allow us to perform such an in-memory query on an ObjectSet ( BTW - I know we could use ObjectStateManager.GetObjectStateEntries to get similar results)?
Thank you
Local is just advanced wrapper (it is ObservableCollection with all its benefits) around functionality provided by ObjectStateManager.GetObjectStateEntries.
I'm researching OData as a RESTful interface for a database. The data is structured in a very unusual way and normal tables and rows do not apply, in fact, some stuff just exists in in-memory collections and objects.
Can I build my own arbitrary mapping system between the entities that make up 'feeds' and the sources behind, this might mean aggregating from sources and building the entities on the fly?
I'm just looking for yes/no (why not) and maybe some pointers to relevant reading material.
Many thanks
Luke
Yes and no.
You can build an OData feed of anything. In a WCF Data Service implementation of same, you can implement IDataServiceMetadataProvider.
However, the easiest way to define an EF data service is:
public class MyOData : DataService<MyObjectContext>
...and that won't work if you need to return non-entity objects. Such services are limited to entities and simple types only.
So yes, you can do it, but it's quite a bit more work than the one-liner above!
I have been reading when using LINQ to entites a query is of type IQueryable before it is processed but when the query has been processed, it's no longer an IQueryable, but an ObjectQuery.
In that case, is it correct to write methods from my layer (repository layer) to return IQueryable?
Do I need to cast?
Why would I want to return an ObjectQuery?
I'm coming from a LINQ to SQL background where things were always IQueryable but EF seems to have changed this.
Any help really appreciated.
My repositories always returns IQueryable. The reason for this is that IQueryable is not dependent on EF whereas ObjectQuery is. So if I want my other layers to be persistance ignorant I don't want to introduce dependency on ObjectQuery.
ObjectQuery is implementation of IQueryable with several additional features. First feature you will quickly discover is Include function which is need for eager loading of navigation properties (related entities). Second feature is EQL - entity query language. EQL is second way how you can query your conceptual model. It has similar syntax as SQL. You can write simple query as string, pass it to ObjectQuery constructor and execute query or use it in Linq-To-Entities.