Entity Framework Feature Suggestions

Support interfaces as entity and complex types

It's unfortunate not to be able to mark interfaces for EF mapping (code first). This will allow to really abstract the implementation. Allows a unique representation of the data in the context of RIA Services (if Ria Services allows also for interface 'mapping'). This won't be very hard to implement since EF is happy when it subclasses... For the benefits: imagine you have only interfaces to declare your model. On the server side, you use EF to get your interfaces 'filled' from DB. on the client side you get those same interfaces filled by RIA services... You can reuse any algorithm against your data.
I am not sure this idea will be implemented one day. If it is then I have many other ideas to enhance its usage...

454 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…)
    HichamHicham shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    13 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...
      • Alan BlytheAlan Blythe commented  ·   ·  Flag as inappropriate

        EF really needs this feature. Not having this capability is dictating design in other parts of our application. This is going to force us to implement concrete types in other interfaces. End result is a reduced mocking capability.

      • SameerSameer commented  ·   ·  Flag as inappropriate

        Same here. Our team is building a new application and for some reason EF didn't allow us to use interfaces and it is really polluting our cross team application as our other teams have to program to abstract base classes instead of interfaces (or we have to introduce new interfaces for every team that needs our API). Next version of EF needs to have support for interfaces. Period.

      • Craig BolandCraig Boland commented  ·   ·  Flag as inappropriate

        We are currently building on a DDD design and all of our entities implement an entity interface like so:

        interface IOrderItem { ... }

        interface IOrder
        {
        IColllection<IOrderItem> OrderItems { get; }
        }

        class Order : IOrder { ... }

        We built the application on EF5 and it works for us as expected. However, the issue described in Work Item #1977 is a breaking change and is blocking us from upgrading to EF 6+.

      • Claes RyomClaes Ryom commented  ·   ·  Flag as inappropriate

        Please consider to support this feature. Exposing the concrete classes between layers because the EF does not support interfaces was not my intention. Let's get the interfaces into EF! :-)

      • brettmanbrettman commented  ·   ·  Flag as inappropriate

        Please support this. As others have stated, I'm a bit surprised it isn't supported out of the box. EF will be a much more attractive choice if this gets sorted out.

      • Rachael RossRachael Ross commented  ·   ·  Flag as inappropriate

        PLEASE SUPPORT!!!!!!! Being new to EF, after I created my entire code first model with interfaces included, I was absolutely shocked that EF didn't offer support for this. Very close to moving to NHibernate at this point just to keep my domain model pure.

      • Per BragePer Brage commented  ·   ·  Flag as inappropriate

        This is basically what is keeping me from using EF for any serious project. Mapping against private fields would be nice, but it is not a must have like this. DbSet<TInterface> and being able to have the entire model modelled with interfaces. Hint! Have a look at how NHibernate (old Fluent extension) does this Proxy<TInterface> in the concrete class mapping.

      • Anton FrattaroliAnton Frattaroli commented  ·   ·  Flag as inappropriate

        I would use an ORM if EF had this feature. I consider it required if I were to open up an API to outside developers. The other suggested features on this site seem less important, when I can just write my own raw ADO.Net code to accomplish the tail cases where EF is inadequate.

      • Aravind ChembetiAravind Chembeti commented  ·   ·  Flag as inappropriate

        I would consider interface inheritance is one of required features, without which I am limited by another .Net constraint: a class can inherit from only one base class.

      • Juliano GonçalvesJuliano Gonçalves commented  ·   ·  Flag as inappropriate

        We stumbled upon this problem just a few hours ago. We were trying to map an inheritance chain using TPT against a base interface and discovered that EF does not support mapping to interfaces at all.

        We had to go from an IEvent interface to a EventBase abstract class for it to work, but this pollutes the whole solution and is seemingly the exact same thing for EF.

        I wonder what exactly complicates things here. Isn't it trivial to implement this in the next version of EF Code First?

      • Terry CoattaTerry Coatta commented  ·   ·  Flag as inappropriate

        I agree. It makes unit testing more challenging when one is forced to expose the concrete classes used in the data layer. In particular, I would like to be able to declare a DbSet<interface> and then provide a code first indication of the concrete type being mapped. This would mean that DbSet<interface>.AsQuerable() would have type IQueryable<interface> which is much easier to deal with when you are using a mocking framework.

      Feedback and Knowledge Base