Entity Framework Тип свойства интерфейса навигации

Question

Я создаю приложение, использующее сущность Framework code-first, и я столкнулся с некоторыми проблемами с ограничениями EF, следуя принципу segration интерфейса.

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; } 
} 

Проблема процессы и линии собственность причина не может выяснить, какой класс в конкретном типе (я полагаю).

Я знаю, что я мог бы достичь почти то же самое, используя абстрактные классы. Причина, почему я не просто сделал это, так это то, что я ошибаюсь, чтобы изменить модель из-за ограничений EF.

Какой будет лучший способ решить эту проблему? Любая альтернатива EF, которая позволяет интерфейсам как свойство навигации.

Answer 1

Существует только один способ решить эту проблему - использовать конкретные классы, сохраненные в базе данных. EF не поддерживает другой способ. Даже использование абстрактных классов не поможет вам, если вы не нарисуете все дерево наследования (не делайте этого).

Если вы хотите, чтобы объект отображал интерфейс, вы должны предложить второе свойство без сопоставления, которое будет выполнять преобразование из свойства, отображающего конкретный тип внутри.

Просто, если вы хотите использовать EF, вы должны согнуть свою архитектуру, чтобы следовать ее набору функций.

Answer 2

Я знаю, что это старая нить, но в случае, если кто-то другой сталкивается с ней, у меня есть несколько лучшее решение для использования EF.

В принципе у меня есть два интерфейса

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

и

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

Я держу интерфейс IProduct в моем проекте контрактов, поэтому он до сих пор полностью не зависит от остальной части моей модели, но я поставил IEFProduct в моем проекте модели, поскольку это содержит конкретную реализацию. Это означает, что я не могу получить доступ к процессам и линиям из всего, что реализует интерфейс, а не конкретный тип, но в моем случае это вызвало проблему.

В другом направлении будет использоваться DTO.

Ваши модели будут использовать интерфейс, но ваша фактическая реализация EF будет использовать Concrete DTO, в слое данных вы бы отображали их вручную либо с помощью Automapper - конечно, это может иметь небольшое влияние на производительность.