1

我需要有关 3 层架构中的数据库访问的帮助。我正在 asp.net 和 linq 中开发应用程序。数据库中至少有 9 个主表，总共有 22 个表。为了管理数据，我需要为每个主表使用一个视图。

我的问题是在运行时更方便还是更快执行？

  1. DataAccessLayer在使用 linq时使用页面级查询（使用具有至少 5-6 个表的多个连接）
  2. 使用视图并参考它们DataAccessLayer
  3. 将所有查询添加到存储过程，然后将它们全部绑定。

哪一个是最佳实践？运行时视图是否会使页面变重？

4

2 回答 2

2

我认为最佳实践将是您的 #1，但如果性能需要，您必须对使用 #2 或 #3 来解决问题持开放态度。换句话说，尽可能使用#1 运行，但仅在需要时才愿意使用#2 或#3 来改进代码的这些部分。

我发现（并同意@nonnb）使用 Linq2SQL/ORM 的生产力提高和灵活性使其成为大多数时候正确的选择，但有时你需要愿意使用战略SP 在你的整体计划中——它不是一个非此即彼的决定；根据需要使用两者。通常 SP会更快，但大多数时候不足以对您的应用程序产生影响 - 但它们应该保留在您的工具集中，因为在正确的场景中，它们可以在真正需要时做出巨大的改进。

于 2012-08-30T12:25:19.613 回答
2

Linq2SQL 查询通常以数据库上的参数化查询的形式结束。

有很多关于 SO 比较性能差异的讨论，例如存储过程是否比现代 RDBMS 上的内联语句更有效？和存储过程与参数化查询

我相信大家的共识是，像 Linq2SQL 这样的 ORM 所提供的灵活性的好处通常超过了任何感知到的性能损失。

IMO，LINQ2SQL 将完成 90% 的工作，满足您的大多数数据访问需求，如果您有任何特殊需求需要 PROC 更有意义（例如，真正的数据密集型或批处理事务），您可以编写一两个procs 和这些到你的DataContext.

但是，当我们这样做时，我不会在新项目中考虑使用 Linq2SQL。为什么不看看 Entity Framework 4+？ （OP 正在使用 .NET 3.5）

编辑

如果您的表外键设置正确，当您将底层表拖到 Linq DBML 中时，您会发现几乎不需要“手动”加入，因为 ORM 将为您处理底层导航。

例如

var myUpvotes = Users.Where(u => v.UserId == someUser)
                     .Votes.Where(v => v.Upvote == true)
                     .Count();

您需要的一个概念是Eager vs Lazy loading。这肯定会影响您的“加入”的性能

于 2012-08-30T11:46:05.423 回答