3

Возможно ли создать свойство в POCO, которое представляет собой набор ComplexTypes?ComplexType Collection Property в EF 4.1 с кодом First

[ComplexType] 
public class Attachment 
{   
    public string FileName { get; set; } 

    public byte[] RawData { get; set; } 

    public string MimeType { get; set; } 
} 

public class TestObject 
{ 
    public TestObject() 
    { 
     Attachments = new List<Attachment>(); 
    } 

    public virtual ICollection<Attachment> Attachments { get; set; } 
} 

У меня есть ощущение, что это невозможно ... Я делал все возможное, чтобы исследовать его, и мне кажется, как ComplexTypes больше проблем, чем они стоят по нескольким причинам.

ответ

2

Ваши чувства правы: это невозможно. Цель сложного типа - вставить его свойства в виде столбцов в таблицу родительского типа. Как можно встроить динамическую коллекцию в строку таблицы и что вы ожидаете от коллекции сложного типа с точки зрения ее сохранения?

Что вам нужно, это обычное навигационное свойство (в основном атрибут [ComplexType] необходимо удалить). В моем вопросе ваши отношения между TestObject и Attachment похожи на отношения между Order и OrderItem: OrderItem однозначно относится к одному Order (он имеет один внешний ключ, который указывает на заказ), и возможно каскадное удаление включено, что гарантирует, что элементы удаляются вместе с их порядком и который подчеркивает зависимость элементов в заказе. Какие еще и специальные вы хотите достичь, сделав OrderItems/Attachments сложным типом?

+0

Я пытался использовать ComplexType, потому что вложения в моем уме очень похожи на другие примеры, которые я видел с помощью ComplexTypes (имена, адреса и т. Д.). Я думал, что имеет смысл объявить этот тип один раз и повторно использовать это несколько мест. Я думаю, что сохраню это, но просто заверните ComplexType в другой POCO, где мне нужно. Благодарю. – DMC

3

Это невозможно, но не из-за концептуального несоответствия, как сказал Слаума, а потому, что EF его не реализует. Посмотрите на this answer для получения дополнительной информации о поддержке коллекции - помимо других вещей.

Это, вероятно, лучше сделать его сущностью. Вам не нужно обертывать его: у вас может быть базовый тип Attachment, который равен , но не указан, а затем конкретные подтипы.

+0

Интересно! Вы знаете, как NH реализует коллекцию сложного типа на уровне магазина? Я мог бы создать нечто вроде «скрытой» таблицы (не соответствующей сущности в модели, аналогичной таблице соединений «много-ко-многим» в EF) и внутренне управляемой инфраструктурой ORM. И каждый раз, когда загружается родительский объект, коллекция также извлекается путем объединения в базу данных. Это похоже на это или подобное? – Slauma

+1

@Slauma: сложный тип не отличается от скалярного типа. Для коллекции ints у вас будет таблица с двумя столбцами: значение и FK для родителя. Для вложения у вас будет FK плюс остальные 3 столбца. Отношения всегда «один-ко-многим», а не многие-ко-многим, потому что сложные типы не существуют сами по себе. Загрузка может быть нетерпеливой или ленивой, как и любая другая коллекция. –

+0

Ницца, кажется, хорошая особенность в NH! – Slauma

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