实体框架代码首先和原始类型的集合 [英] Entity Framework Code First and Collections of Primitive Types

问题描述

当创建包含原始类型集合并由EF Code First持久化的POCO类时，我发现的最好的建议是创建一个具有ID加上原始类型的新类：

When creating POCO classes that contain collections of primitive types and are persisted by EF Code First, the best advice I have found so far is to create a new class that has an ID plus the primitive type:

具有简单数组的实体框架和模型

如果我现在有几个类需要类型为 ObservableCollection< string> 的属性，并将其替换为 ObservableCollection< EntityString> （其中 EntityString 是具有Id和字符串属性的自定义类型），我最终得到具有多个外键列的表 EntityString ，具有多个外键列，每个属性类型为 ObservableCollection< EntityString> 这样的属性。

If I now have several classes that require properties of type ObservableCollection<string> and replace them with ObservableCollection<EntityString> (where EntityString is a custom type with an Id and a string property), I end up with a table EntityString that has multiple foreign key columns, one for each property of type ObservableCollection<EntityString> across all concrete types with such properties.

这导致 EntityString 中大部分为空的外键列的膨胀

This leads to a bloating of mostly-null foreign key columns in the EntityString table.

一种方法是创建一个 EntityString 的子类，并使用 Table per Type 模型。然而，这需要对对象模型进行尴尬的更改，只需要适应实体框架。

One approach would be to create a subclass of EntityString and use the Table per Type model for those subclasses. However, that requires making awkward changes to the object model simply to accommodate Entity Framework.

问题：

• 封装类型是管理 Collection< PrimitiveType> 的最佳方式？


• 如果是，那么pro和con允许多个（多个）外键列与每种类型创建自定义表（以尴尬的模型为代价）？

• Is the encapsulating type the best way to manage Collection<PrimitiveType>?
• If so, what are the pro's and con's of allowing multiple (many) foreign key columns vs. creating custom tables per type (at the cost of an awkward model)?

推荐答案

将简单类型提升为实体是一种选择。如果要在更多关系中使用新的基本类型实体，最好从该实体完全删除导航属性，并使用独立关联（无FK属性）。

Promoting simple type to entity is one option. If you want to use that new primitive type entity in more relations it is better to completely remove navigation properties from that entity and use independent association (no FK properties).

public class StringEntity
{
    public int Id { get; set; }
    public string Text { get; set; }
}

和映射：

modelBuilder.Entity<Foo1>().HasMany(f => f.Strings).WithOptional();
modelBuilder.Entity<Foo2>().HasMany(f => f.Strings).WithOptional();

在数据库中，每个相关主体将获得新的可空的FK - 除了创建之外，没有办法避免它特殊 StringEntity 每个主体的类（不要使用继承，因为它影响性能）。

In database you will get new nullable FK per related principal - there is no way to avoid it except create special StringEntity class per principal (don't use inheritance for that because it affects performance).

有一个另外：

public class StringEntity
{
    public int Id { get; set; }
    public List<string> Strings { get; private set; }

    public string Text 
    {
        get
        {
            return String.Join(";", Strings);
        }

        set
        {
            Strings = value.Split(";").ToList();
        }
    }   
}

在这种情况下，需要相关的实体类型（和附加表），但是您的实体被额外的属性 Text 污染，这仅用于持久性。

In this case you don't need related entity type (and additional table) but your entity is polluted with additional property Text which is only for persistence.

这篇关于实体框架代码首先和原始类型的集合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！