Entity Framework Navigation property interface type

Question

I'm creating a application using entity framework code-first and i'm facing some problems with the limitations of EF while following the interface segration principle.

    public interface IProduct
{
    int Id { get; set; }
    ICollection<IProcess> Processes { get; set; }
    ICollection<ILine> Lines { get; set; }
    String Description { get; set; }
    String Number { get; set; }
    String Name { get; set; }
}

Problem is the Processes and Lines property cause it can't figure out which class in the concrete type (I presume).

I know that i could achieve almost the same by using abstract classes. Reason why i haven't just done this is that i find it wrong to change the model because of EF limitations.

What will be the best way to solve this? Any alternative to EF that allows interfaces as navigation property.

Answer 1

There is only one way to solve this - use concrete classes persisted to the database. EF doesn't support any other way. Even using abstract classes will not help you unless you map the whole inheritance tree (don't do that).

If you want property exposing an interface you must offer second non mapped property which will do the conversion from property exposing concrete type internally.

Simply if you want to use EF you must bend your architecture to follow its feature set.

Answer 2

I know this is an old thread, but in case anyone else comes across it I have a slightly better workaround for using EF.

Basically I have two interfaces

public interface IProduct
{
    int Id { get; set; }
    String Description { get; set; }
    String Number { get; set; }
    String Name { get; set; }
}

and

public interface IEFProduct
{
    ICollection<IProcess> Processes { get; set; }
    ICollection<ILine> Lines { get; set; }
}

I keep the IProduct interface in my contracts project, therefore it still completely independent on the rest of my model, but I put the IEFProduct interface in my Model project as this holds the concrete implementation. It means that I cannot access the processes and lines from anything that implements the interface rather than the concrete type, but in my case it got me around the issue.

The other way forward would be using DTOs.

Your models would all use the interface, but your actual EF implementation would use Concrete DTOs, in the data layer your would map between them either manually or using Automapper - of course this may have a slight performance impact.