在 EF6 中是不是有可能有一个 DbSet<T> 仅存在于内存中，而其余的是真实表？

Posted 2023-03-31

【中文标题】在 EF6 中是不是有可能有一个 DbSet<T> 仅存在于内存中，而其余的是真实表？

【英文标题】：Is it possible in EF6 to have a single DbSet<T> that exists only in memory while the rest are real tables?在 EF6 中是否有可能有一个 DbSet<T> 仅存在于内存中，而其余的是真实表？

【发布时间】：2018-04-05 18:05:58

【问题描述】：

我有一个DbSet<Account> Accounts get; set; ，它有一个相当典型的实体框架帐户表。由于其他表中的外键，它在 OnModelCreating(DbModelBuilder modelBuilder) 中有几个引用，并且在整个代码中使用了 70 多个引用，如您所料（LINQ、Fluent API 等）。

我想从外部来源获取通常来自 Accounts 表的数据，而无需更改引用该 DbSet 的任何其他代码，除了必要时可能删除 FK。

理想情况下，它仍应完全像以前一样运行，就像普通的 DbSet 一样，但我需要从表格以外的其他来源即时获取和提供数据。

使用 Entity Framework Core 我已经看到了使用内存数据库的概念，至少用于测试。我不知道 Entity Framework 6 中是否存在此功能，或者是否有任何方法可以让我利用它或仅将它用于单个表。

理论上，我可以简单地添加代码，在正确的时间更新/刷新内存表中的数据，同时其余表仍然像以前一样存在于数据库中（减去一些 FK，因为我'我不确定在这种情况下这将如何工作，但我们假设现在摆脱 FK 是一个小问题）。

有谁知道这样的事情是否可行？

【问题讨论】：

我从您的描述中了解到，Accounts 属性没有理由成为DbSet，因为它没有在 EF 模型中映射，因此它永远不能在一个 LINQ 语句中使用映射实体（在joins 或导航属性中）。此外，您只能将DbContext 连接到一个数据库。我认为在你的上下文类中甚至有这个外星数据源是非常不自然的，很容易忘记它需要特殊处理。

@GertArnold 我同意，这不是最好的解决方案，但如果我能成功的话，它可能是最便宜的解决方案......

【参考方案1】：

我了解您正试图通过诱使 EF/LINQ 认为数据来自您的主要数据源以外的其他来源来获得 EF/LINQ 的好处。我倾向于同意 GertArnold 的观点，即选择您所描述的解决方案可能会有问题。

改用另一种机制来更新来自辅助来源的主要数据以便与 EF 更加一致不是有意义吗？您是否出于某些原因不想让这些数据与应用程序的主数据源复制/同步？

【讨论】：

我认为这应该是评论而不是答案。

看起来很公平。我缺乏发表评论所需的声望。无论如何，祝你好运找到解决方案。有时，当更简单的方法就在我们面前时，我们会在脑海中产生一个想法并继续解决问题，所以我只是想提供帮助。在我看来，真正的解决方案似乎是简单地导入数据，因为这可能是获得 EF 奖励的更常见方式。

我明白，我只是让你知道，以防某个 mod 删除你的答案，因为它不是问题的直接答案（它可能发生），然后你可能会因为你花时间而生气写它，不要让你学得很辛苦！非常感谢您的意见。