logo标签列表

实体框架V4："仅代码"性能考虑

c#.netentity-framework
4
我即将开始一个新项目，想知道“仅代码”是否是正确的方式。我们也在考虑通过设计师实现另一种模型优先方法，但宁愿在EF设计器之外设计我的领域模型。
我们的领域可能包含100多个实体。我读到说大量实体可能会使EF变慢（例如：创建上下文和第一次调用SaveChanges）。
由于没有EDMX文件来存储元数据，这种方法是否可能会更慢？我搜索了网站，但没有找到任何相关信息。
我知道这仍然只是CTP版本，缺少很多功能，但我现在只是寻求输入/指导。
那些认为大量实体会降低上下文第一次使用速度的人，是那些还没有发现编译时视图生成功能的人。 - Craig Stuntz
好的，这很有趣。但是这个功能是否适用于“仅代码”？ - Joepro
我不知道。也许Alex James会插话？ - Craig Stuntz
3个回答
4

在内部，Code-Only仅缓存元数据，因此一旦创建了第一个上下文，您应该会发现Code-Only和EDMX方法之间的性能差异非常小。

您说得对，大量实体可能会减慢EF的速度。

预生成视图通常被推荐用于帮助处理大型模型的性能。但是，该功能依赖于有一个EDMX文件，因此不出所料，它不能与Code-Only一起使用。

但是，如果您发现需要预编译视图，则可以始终使用CodeOnly的ToEdmx()功能，从Code-Only世界移动到标准的EDMX世界。当然，一旦进入EDMX世界，您可以预编译视图。

然而，这不一定是我的做法。

我认为具有100个或更多IQueryable属性的上下文从可用性角度来看并不理想。

因此，与其摆脱Code-Only以预生成视图，我可能会利用Code-Only的能力，使其易于创建更小的定向子域，以最小化您正在处理的应用程序部分的模型的有效大小。

结果将是一些快速、易于使用的ObjectContexts，专门针对当前任务集。

这样做IMHO（在我看来）更具吸引力。

希望这能帮助到您。

Alex

+1：这通常是正确的。请参见https://dev59.com/wUnSa4cB1Zd3GeqPOof3。但我希望不是所有的EntitySets都自动成为ObjectContext的属性（或者至少可以关闭）。理想情况下，只有聚合根才是公共属性。 - Craig Stuntz
糟糕，链接错误了。正确的链接应该是http://devlicio.us/blogs/casey/archive/2009/05/14/commercial-suicide-integration-at-the-database-level.aspx。 - Craig Stuntz
1
我们明确地努力支持代码中的聚合根。例如，您可以拥有一个只有一个ObjectSet<>的ObjectContext，但它很容易拥有多个EntitySets。配置也很容易。 - Alex James
1
我非常喜欢拥有多个ObjectContext并能够根据我的需求进行配置的想法。看起来Code-Only确实是正确的选择，迫不及待地期待下一个版本的发布。谢谢你们两个。 - Joepro
是的，我同意。Code-only很好地支持了聚合根的概念。但我仍在使用v1版本，当我迁移到v4时，我无法轻松地转向Code-only。我们拭目以待。对于DB first和model first，如果我在EntitySet上有一个“Visibility”属性（public/private）会很不错。 - Craig Stuntz
是的...这是我一直在倡导的事情。不过不在.NET 4.0中实现。 - Alex James
1

由于.NET 4，包括EF4目前仍处于Beta 1阶段，因此您不会得到任何有用的一般性答案。针对您的特定情况，为什么不进行测试呢。

创建一个实体模型，并运行一些性能测试。然后扩展模型以具有更多实体并重新运行测试。如果模型中的实体数量对性能产生影响，则应该看到性能差异。

请记住排除负载效应，除非您只关心启动、执行单个操作然后关闭的应用程序。

这不完全是我想要的答案，但考虑到上下文，这可能是最好（唯一？）的选择。 - Joepro
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接