我的EF6代码优先模型似乎非常低效，但我不知道如何改进它.我错过什么了吗?

本文关键字：何改进 我不知道 错过 什么 代码 EF6 模型 非常低 我的 | 更新日期: 2023-09-27 18:07:37

我目前使用实体框架6使用代码优先的方法在asp.net中建模两个类。用户可以创建一个Widget，其中一个Widget拥有最多5个WidgetOptions的集合。这些选项主要是字符串，但有与它们相关的元数据，其他用户需要与之交互(因此它们不只是字符串的集合)。目前，我的类看起来像这样:

Widget {
    public string Name {g;s;}
    ... //more fields
    public string ICollection<WidgetOption> Options {g;s;}
}
WidgetOption {
    public string Option {g;s;}
    ... //more fields
}

这显然看起来很简单，但这是我的想法。因此，当前，当用户在UI中创建小部件时，控制器根据用户输入的字符串创建WidgetOptions列表，将WidgetOptions分配给widget，然后保存到数据库上下文。如:

Create(WidgetFormViewModel vm) {
    var options = vm.WidgetOptions.Select(wo => new WidgetOption(wo)).ToList();
    var widget= new Widget { 
        Options = options,
        // ... other fields from vm
    };
    _context.Widgets.Add(widget);
    _context.SaveChanges();
    return RedirectToAction("Index", "Home");
}

问题是许多用户可能会重复WidgetOption字符串。例如，许多用户可能会将一个选项命名为"red"以使Widget变成红色(虽然这看起来很奇怪，但实际情况更有意义)。实体框架目前将类建模为在Widget中没有引用WidgetOption的列，而WidgetOption有Id、Option和Widget_Id列。

因此，如果两个用户使用"红色"WidgetOption创建一个Widget，则在WidgetOption表中将创建两行。每个都有一个惟一的Id，每个都有相应的Widget_Id。就空间而言，这似乎非常低效，但我可能错了(因为它并没有我认为的那么多空间被浪费)。我想，即使我有一个单独的表，只有唯一的WidgetOption字符串，我仍然需要一个关系表，将一个小部件连接到许多WidgetOptions。如果关系表中的WidgetOption_Id比字符串本身小得多，这可能比当前模型更有效?不过，我必须搜索用户输入的每个字符串，看看它是否已经创建。所以我要牺牲速度来换取存储空间。

我不确定我是否想得太多了，但我只是觉得有一个重复WidgetOptions的表很奇怪。如果只有几个唯一的选项字符串，那么多对多关系就更有意义，而如果每个选项字符串都是唯一的，那么当前模型就有意义。似乎正确的选择只能通过弄清楚在实践中发生的这一端来解决。

我的EF6代码优先模型似乎非常低效，但我不知道如何改进它.我错过什么了吗?

这样重写你的Widget和WidgetOption实体:

Widget {
    public string Name {g;s;}
    ... //more fields
    public virtual ICollection<WidgetOption> WidgetOptions {g;s;}
}
WidgetOption {
    public string Option {g;s;}
    ... //more fields
    public virtual ICollection<Widget> Widgets {g;s;}
}

告诉实体框架在Widget和WidgetOption之间定义many-to-many关系。我相信这应该能解决一直困扰你的问题。不过，添加WidgetOptions可能需要对代码做一点改动。

相关文章：