查看或存储过程或Linq查询

Question

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

我的问题是什么在运行时或更快的执行更方便？

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

哪一个是最佳做法？视图是否会在运行时使页面变重？

Answer 1

Linq2SQL查询通常最终会成为数据库中的参数化查询。

有很多关于SO的讨论，比较Are Stored Procedures more efficient, in general, than inline statements on modern RDBMS's?和Stored Procedures vs Parameterized Queries

等性能差异

我相信这一共识是，像Linq2SQL这样的ORM所带来的灵活性的好处通常会超过任何感知到的性能损失。

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

然而，虽然我们在这里，但我不会在新项目上考虑Linq2SQL。为什么不看实体框架4 +？ （OP使用的是.NET 3.5）

修改

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

e.g。

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

您需要的一个概念是Eager vs Lazy加载。这肯定会影响你的“联接”

的表现

Answer 2

我认为最佳实践将是你的＃1，但如果性能需求需要，你必须保持开放思想，让＃2或＃3对问题产生影响。换句话说，尽可能使用＃1运行，但只有在需要时才愿意使用＃2或＃3来改进代码的这些部分。

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