Search for existing 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...

323 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Hicham shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Anonymous commented  ·   ·  Flag as inappropriate

    I have seperated my interfaces into a different project and now I am unable to include the complextype in my interface. We need this.

  • Wesley Kenis commented  ·   ·  Flag as inappropriate

    Not to mention unit testing and realty abstracting domainnfrom persistence without the need for additional unit of work and repository constructs.

  • Sam Nelson commented  ·   ·  Flag as inappropriate

    lfbicalho mentioned using DI to control which implementation EF constructs. Possibly if no DI binding was made, a dynamic proxy class that implements the interface could work too?

  • lfbicalho . commented  ·   ·  Flag as inappropriate

    I think that interfaces should be useful to create multiples dbcontexts for examples if you have modules in your project, you could change the implementation using a DI.

  • Alan 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.

  • Sameer 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 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 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! :-)

  • brettman 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 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 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 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 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ç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?

← Previous 1

Feedback and Knowledge Base