EF 4.1 中使用 Code First 的 ComplexType 集合属性

Posted 2023-04-12

【中文标题】EF 4.1 中使用 Code First 的 ComplexType 集合属性

【英文标题】：ComplexType Collection Property in EF 4.1 with Code First

【发布时间】：2011-08-25 19:36:29

【问题描述】：

是否可以在作为 ComplexType 集合的 POCO 中创建属性？

[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 比它们的价值更麻烦，原因有很多。

【参考方案1】：

这是不可能的，但不是因为 Slauma 所说的概念不匹配，而是因为 EF 没有实现它。请查看this answer，了解有关收集支持的更多详细信息-除其他外-。

也就是说，让它成为一个实体可能会更好。您不需要包装它：您可以有一个 未映射 的基本 Attachment 类型，然后是特定的子类型。

【讨论】：

有趣！您知道 NH 是如何在商店级别实现复杂类型集合的吗？我可以将类似“隐藏”表的图像（不对应于模型中的实体，类似于 EF 中的多对多连接表）并在内部由 ORM 框架管理。每次加载父实体时，也会通过数据库中的连接来获取集合。是这样的还是类似的？

@Slauma：复杂类型与标量类型没有区别。对于整数集合，您将有一个包含两列的表：值和父级的 FK。对于附件，您将拥有 FK 和其他 3 列。关系总是一对多，而不是多对多，因为复杂类型本身并不存在。加载可以是急切的或懒惰的，就像任何其他集合一样。

【参考方案2】：

你的感觉是对的：这是不可能的。复杂类型的目的是将其属性作为列嵌入到父类型的表中。如何将动态集合嵌入到表格的一行中？您对复杂类型集合的存储方式有何期望？

你需要的其实是一个普通的导航属性（基本上[ComplexType]属性需要去掉）。在我看来，TestObject 和Attachment 之间的关系就像Order 和OrderItem 之间的关系：OrderItem 唯一地指向一个Order（它有一个指向订单的外键) 并可能启用级联删除，以确保项目与其订单一起被删除，并强调项目对订单的依赖性。通过将OrderItems/Attachments 设为复杂类型，您还想实现什么特别的目标？

【讨论】：

我试图使用 ComplexType，因为我脑海中的附件与我在 ComplexTypes 中看到的其他示例（名称、地址等）非常相似 - 我认为声明是有意义的该类型一次并在多个地方重用它。我想我会保留它，但只需将 ComplexType 包装在我需要的另一个 POCO 中。谢谢。