How can we improve Entity Framework or Entity Framework Core?

Vastly improve LINQ translation

LINQ to SQL is the legacy alternative to EF. EF should support almost everything that L2S always did for two reasons:

a) to ease migration
b) because L2S was awesome and we want EF to be as well

Please address the issues mentioned in this post: http://scatteredcode.wordpress.com/2011/06/21/why-entity-framework-4-1s-linq-capabilities-are-inferior-to-linq-to-sql/

I did not author it, but I found many of those attempting to migrate a bug codebase. I was forced to abandon the migration because the issues were so many.

189 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    started  ·  Diego VegaAdminDiego Vega (Program Manager, Entity Framework) responded  · 

    EF7’s LINQ implementation supports mixed server and client-side evaluation, which helps with some of the issues explained in the blog post. We are looking into implementing many other LINQ improvements in EF7.

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        The biggest drawbacks are while using projections (in EF6.x at least):
        - no support of custom constructors (with parameters)
        - bad decimal/float/double conversion (rarely works)
        - also if having complex property multiple times in projections, we must set all the variables we set before and also in the same order - this is a big NO-NO-NO!

      • markmark commented  ·   ·  Flag as inappropriate

        It is great to hear that you started working on this!

        Also consider the following pattern:

        from x in someTable
        ...
        select new { x, someLocalValue = LocalFunction(x) }

        A simple way to implement this would be to consider only the final Select in a query and localize all expressions that depend on untranslatable items.

        A more powerful way would be to push operators like Skip and Take "upwards" over the final select. That would allow for more flexible use of local functions without performance loss. That way we can have store-side paging on a query that has a final local code projection.

        It would also be a powerful approach to move local function calls to later points in the query if possible. Example:

        table
        .Select(x => new { x, local = F(x) })
        .Take(10)
        .OrderBy(x => x.x.something)

        becomes
        table
        .Select(x => new { x })
        .Take(10)
        .OrderBy(x => x.x.something)
        .AsEnumerable()
        .Select(x => new { x, local = F(x) })

        Push local functions down, push store operations up. If dependencies allow for it.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        Is is especially important to support final projections like:

        from c in db.Customers
        ...
        select CreateMyViewModel(c) //local function

        EF can just pull the c out of the store and hand it to the local function. L2S can do this (efficiently), so it must be possible.

        This is required to migrate from L2S to EF. This feature was so useful that we used it constantly without noticing. A very valuable addition to EF.

      Feedback and Knowledge Base