2010-01-06 5 views
8

Я пытаюсь настроить проект, используя Entity Framework 4, POCO и Code-Only.Использование интерфейса с навигационным свойством

Возможно ли в структуре сущности для типа свойства навигации быть интерфейсом?

У меня есть класс «Задача». Задача может быть назначена пользователю или группе, каждая из которых представлена ​​отдельным классом и хранится в отдельных таблицах. Классы выглядеть примерно так:

public class User : IAssignable 
{ 
    public String Name { get; set; } 
    public int ID { get; set; } 
    public String Email { get; set; } 
    public String Password { get; set; } 
} 

public class Group : IAssignable 
{ 
    public String Name { get; set; } 
    public int ID { get; set; } 
    public String Manager { get; set; } 
    public String Department { get; set; } 
} 

public class Task 
{ 
    public String Title { get; set; } 
    public DateTime DueDate { get; set; } 
    public String Details { get; set; } 
    public IAssignable AssignedTo { get; set; } 
} 

Есть ли способ может свойство AssignedTo как свойства навигации в рамках сущности? Я предполагаю, что для EF должен быть какой-то тип дискриминатора, чтобы знать, нужно ли ему искать в таблице «Пользователи» или в таблице «Группы», но я могу определить отображение с помощью Code-Only или EDMX.

+0

Я также заинтересован в решении этого вопроса. – Ciel

ответ

0

Вы можете сэкономить много работы, используя Инструментарий преобразования текстовых шаблонов (T4), поддерживаемый EF4. Я нашел это после хороших 12 часов ищут пути вокруг вручную, создавая свои Pocos и интерфейсы,

http://blogofrab.blogspot.com/2010/08/maintenance-free-mocking-for-unit.html

Помимо обеспечения блестящей основы для модульного тестирования, он автоматически создает навигационные свойства, основанные на отношениях определенных в вашей модели.

1

Я знаю, что это старый вопрос, но нет, нет особенность Entity Framework (даже последняя версия 6), которая позволяет сопоставить свойство навигации с типом интерфейса.

Вы можете, однако, сопоставить несколько свойств навигации с конкретными типами (и ограничение, которое может быть установлено только один), и предоставить немаркированное свойство вашего типа интерфейса, которое объединяет конкретные свойства навигации в одно свойство. К сожалению, это может сделать ваши запросы более сложными, потому что некоторые запросы должны знать, какие конкретные свойства навигации ссылаются (и вы не можете запросить свое свойство без имени).

Существует значительная сложность вокруг поддержки свойств полиморфной навигации. Подумайте, что должно было бы произойти, чтобы запросить ваше исходное свойство AssignedTo, если вы предположили, что оно сопоставлено с столбцом, таким как AssignedToId int. Вам нужно будет объединить или объединить оба набора User и Group и надеяться, что данный AssignedToId появится только в одном из них. Это подход, используемый для сопоставления типов Table-Per-Concrete (TPC), но он работает только с наследованием классов (а не с интерфейсами) и тщательным планированием для создания различных идентификаторов по участвующим типам.

 Смежные вопросы

  • Нет связанных вопросов^_^