4 ms·
> basically they expect you to use EF. Writing an IQueryable... I don't agree. I don't feel any expectation to use EF. It would not be relevant anyway to our
by SideburnsOfDoom 2y ago
> basically they expect you to use EF. Writing an IQueryable...
I don't agree. I don't feel any expectation to use EF. It would not be relevant anyway to our code.
LINQ is not EF and EF is not LINQ. EF uses LINQ but not vice versa. LINQ is useful without EF.
The LINQ extension methods that we use constantly are on IEnumerable<T> so EF and IQueryable is of no importance to us, but LINQ is used everywhere.
- pjc50 2y ago> IQueryable is of no importance to us I was discussing IQueryable with someone else to whom it was important. In reply to > I could not tell you now how to implement a custom IQueryable (I know where to look but couldn't tell you the rhythms of it) for some database And "for some database" the default answer is "use EF" as the intermediary between LINQ queries and the database itself, rather than delving into IQueryable. LINQ-to-objects is very important and useful but I was talking about something else.
- SideburnsOfDoom 2y agoMy apologies, that reply of mine was a bit argumentative, without regard to which post I was arguing against. Yes, I understand that implementing IQueryable is a beast, but let's not pretend that writing a database connectivity layer was a trivial, everyday activity before IQueryable. It's a specialised, tricky task. IQueryable may not make it easier, but it never was "easy" per se. Nor common, or usually necessary. Or something to do as an exercise "before using something for a serious project" as the grandparent post suggests. YMMV as to how important IQueryable is to your code. On the other hand, if you can write extension methods over "this IEnumerable<T> source" you can extend LINQ. IQueryable being complex is no barrier to that, in any way.