0

我正在努力将现有的 asp.net 应用程序扩展/转换为使用 EF4.0/5.0，但我似乎无法在网上找到对布局设计的最佳实践的共识。我目前的解决方案有超过 100 万行代码，并且目前使用的是笨拙的自定义数据框架。我的数据库有大约 100 个表，大约 300 个存储过程，有些表可能需要多达 1000 万行，但其中只有一小部分用于实体等。典型的页面加载从数据库中恢复以网格形式呈现的实体，然后用户编辑该网格，然后通过首先再次恢复实体然后保存它来保存它。大多数数据不会经常更改，但可能会同时被多人使用。存储过程用于对表等进行分页操作。

所以我的问题是关于如何最好地设置新的 EF 框架来满足我未来编程的需求。到目前为止，我已经看到了以下方法：

  1. 在包含您需要的每个实体/存储过程的 EDMX 上创建。
  2. 拆分 EDMX，以便每个都有特定的表/存储过程子集。

我看到的#1 的好处是实体之间的链接数据将很容易，并且实体可以在数据库范围内有效地缓存。缺点是最初加载模型的成本。成本会这么高吗？如果我实例化整个模型只使用一个实体进行 3-5 次查询，这会是一个大问题吗？

#2 似乎解决了 #1 的一些问题，但由于不想跨模型重复实体，我可能必须实例化 2-3 个模型才能完成工作。这值得吗？

关于如何使用这些模型，我看到了以下内容。

  1. 每次你需要使用一个实体时，你将它与 using 块一起使用，并在块的末尾保存或丢弃更改。
  2. 将模型留在会话中并仅实例化一次，并在需要时重用它。

我可以看到这两者都有其优点和问题。主要是＃1意味着数据将始终与数据库同步，但缓存几乎不存在。#2 允许应用程序几乎拥有数据库的内存副本，但有可能不同步。

我一直在进行的方法是为每个组件创建单独的模型，并使用 using 块立即使用和处理它们。我也有使用相同命名空间的模型。一个典型的代码块是这样的。

Using(CommonType common = new CommonType()){
Using(mytype type = new mytyp()){
  // execute query on mytype
  // manipulate data using common type

} }

所以我该怎么做？我的假设完全偏离了这里吗？

我一直在使用一些资源来提供此信息：http: //msdn.microsoft.com/en-us/data/hh949853 https://blogs.msdn.com/b/adonet/archive/2008/ 11/24/working-with-large-models-in-entity-framework-part-1.aspx?Redirected=true

4

1 回答 1

1

启用延迟加载后，从统一模型构建实体不应该占用太多资源，使用您需要的少数位，并在使用完实体后丢弃其余部分。

如果您的实体与支持模式相比特别简单，您可以使用一些 SQL 视图来简化由 EF 创建的实体，或者您可以自己在设计器中修剪它们，无论哪种方式都可能会给您所需的性能。

于 2013-03-28T04:21:24.130 回答