拥有大型dbContext会对性能造成影响吗？

Question

我正在构建一个在一个数据库中有30-35个表的Web应用程序。现在问题是我想将应用程序拆分为3个不同的前端（不同的团队需要不同的东西）。 3个不同的项目。

App1可能使用15-20个表，App2可能使用10个，App3可能使用15个。

我计划创建一个名为Models的项目，该项目包含数据库中所有表的dbContext，并将其用于Web应用程序项目。如果我需要添加或更新数据库，我可以更新一个模型项目。

一位同事提到你应该只包括你需要的东西，所以我应该为每个web项目制作3个独立的dbcontexts，否则会因为包含不必要的表而受到性能影响。

Answer 1

回答标题中的问题：不，我没有看到任何特别大的DbContext。在我工作过的一个项目中，DbContext的定义时间接近一千DbSet秒，配置时间（执行OnConfiguring调用所需的时间和{{1}大约2秒钟，每个实体都是通过Fluent API配置的;所以你可以说只有35个实体的命中率可以忽略不计（如果有的话）。

也就是说，您使用一个或多个OnModelCreating取决于您将如何使用它们。如果有明确的数据分离，您可以清楚地说“此表仅在此处使用”，并且您最终不会重复DbContext，则可以将它们分开。

Answer 2

  

一位同事提到[...]会因为包含不必要的表格而受到影响

当同事说出这样的话时，你告诉他们要么用证据支持这种说法，要么闭嘴。说真的，世界上已经有足够的货物崇拜节目了。它与强制您使用String.Empty的同事相同，因为它比使用""更快，因为他们在博客上读过一次。提示：它不是。

对你听到的每一个主张都应用批评是非常健康的，特别是如果这个主张不是基于任何现实。

是的，加载具有更多属性的类型将需要更多的磁盘I / O和更多的CPU周期。尽管如此，这将是极其微不足道的。你将不注意到这一点。 ^*

如果您正在使用EDMX，那就变成了一个完全不同的故事，因为加载和解析5 MB的元数据会将秒添加到应用程序的加载时间。 ^*

_{^* ：是的，我现在正在寻找这两种说法的来源。}

Answer 3

我认为从性能角度来看这不是问题 - 但我肯定从维护角度看待挑战。

我遇到过类似的情况，我们在不同的功能中共享了一个基于edmx的数据模型。但是每个功能只关注特定数量的表。

有了这个问题，每当我们需要更改任何特定于任何功能的表时，我们就会遇到问题，这需要我们触摸单个数据模型，并且在签入期间也会导致不必要的合并冲突。