建筑设计 DAL 层答案

【问题标题】：Architectural Design DAL Layer建筑设计 DAL 层
【发布时间】：2010-12-24 19:03:27
【问题描述】：

我正在研究中型 Web 应用程序的架构，对于我的 DAL 层，我有 3 个选项

1) 基于传统存储过程的架构（使用 Codesmith 的 NTiers 模板）

2) LINQ To SQL（或 codesmith 的 PLINQO 模板）

3) LINQ 到实体

LINQ to Entity 无法实现，因为我们需要非常快速地启动应用程序，而我们没有足够的技能组合，而且团队从未使用过任何 OR/M 工具，因此学习曲线会很陡峭为他们（这是我在某些地方读到的）

我更喜欢继续使用 LINQ to SQL（但唯一担心的是微软不会进一步支持或增强 LINQ to SQL），从我的角度来看，如果微软不打算进一步增强它，我没有任何问题作为我项目中需要的任何功能都足够了。

现在我的问题是我应该使用 linq to sql 还是应该坚持传统架构？

否则还有其他选择...

编辑：我将使用 SQL Server 作为数据库，它不需要与任何其他数据库交互

设计 DAL 层的最重要目标之一是更快地开发和维护未来数据库表更改，因为未来字段可能会增加或减少。

另外，如果您觉得任何 ORM 工具都非常好并且没有陡峭的学习曲线，那么我们也可以使用

请提供建议

【问题讨论】：

有趣的“微软不会支持或增强 LINQ to SQL”。有链接吗？
这是我在几个博客中听到的，但就在今天我得到了这个链接......我对此更加困惑damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
您可以从此链接中看到：damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40 - Linq-to-SQL 仍然在 .NET 4 中得到完全支持甚至扩展/错误修复 - 所有谣言相反是 FALSE。

标签： asp.net linq-to-sql asp.net-3.5

【解决方案1】：

由于您从事中等规模的项目，我建议您使用 LINQ-TO-SQL，因为这些优势

使用 LINQ to SQL 的优势：

•没有魔术字符串，就像您在 SQL 查询中那样 •智能感知 • 数据库更改时的编译检查 •更快的发展 •工作单元模式（上下文） •自动生成的领域对象是可用的小项目 •延迟加载。 •学习编写linq 查询/lambdas 是.NET 开发人员必须学习的。关于性能：

•在大多数解决方案中，性能很可能不会成为问题。预优化是一种反模式。如果您稍后发现应用程序的某些区域运行缓慢，您可以分析这些部分，在某些情况下甚至将一些 linq 查询与存储过程或 ADO.NET 交换。 • 在许多情况下，延迟加载功能可以提高性能，或者至少可以大大简化代码。关于调试：

•在我看来，调试 Linq2Sql 比存储过程和 ADO.NET 都容易得多。我建议你看看 Linq2Sql Debug Visualizer，它可以让你看到查询，甚至在调试时触发执行以查看结果。 •您还可以配置上下文以将所有sql查询写入控制台窗口，更多信息在这里关于另一层：

•Linq2Sql 可以看作是另一个层，但它是一个纯粹的数据访问层。存储过程也是另外一层代码，我见过很多部分业务逻辑已经实现到存储过程中的案例。在我看来，这更糟糕，因为您将业务层分成两个地方，开发人员将更难获得业务领域的清晰视图。

【讨论】：

LINQ 允许您这样做，LINQ2SQL 只是众多实现之一。您无需使用 LINQ2SQL 即可使用 LINQ2XML 或 LINQ2Objects。微妙但重要的区别。

【解决方案2】：

没有绝对首选的方式来编写 DAL。这些都是选项。选择哪一个取决于您的项目、您的技能和您的倾向。

通常，使用 LINQ 可以提高工作效率。另一方面，使用存储过程构建的 DAL 预计会执行得更快。

仅当您需要一些特定查询时才会出现问题，而默认 LINQ to SQL 提供程序无法以极快的速度生成这些查询。在这种情况下，您将不得不利用您的 LINQ 代码在需要的地方插入您的自定义存储过程。

关于 LINQ to SQL 的支持和进一步的开发，很久以前就已经有了基础。所以没有官方进一步的发展。注意：这适用于 LINQ to SQL（它将被 EF 接管）关系解决方案，而不适用于主要的 LINQ 功能。

实体框架在其 v.1 中只受到了大量批评。建议您等到 v2 发布。

LINQ（通过实体框架或任何其他流行的 ORM）最重要的限制是它不支持 1 到 n 映射。也就是说，您的每个 LINQ 类只能映射到一个表，而不是代表其他几个视图的某种视图。也许它对你不重要，但也许它是。取决于你的项目。

【讨论】：

你能推荐任何学习曲线不陡峭的 ORM

【解决方案3】：

存储过程与 ORM 的争论由来已久，不太可能很快得到解决。我的建议是使用 ORM（在您的情况下为 Linq-to-Sql）。

是的，存储过程总是会更快，因为查询是预编译的。您必须问自己的真正问题是您是否拥有这样一个性能密集型系统，以至于您的用户会真正注意到差异。请记住，使用存储过程意味着您将需要手动编写所有自己的查询，而使用 ORM 会为您执行此操作。这通常意味着 ORM 将加快您的开发速度。

既然你提到加快开发时间是你的目标之一，我会推荐 Linq-to-Sql - 否则你基本上会自己编写整个 DAL。

【讨论】：

【解决方案4】：

您提供的所有选项都有很大的缺陷。它们都不符合您提出的要求。

您需要优先考虑对您来说最重要的事情。

如果学习曲线是您最大的问题，如果您已经熟悉 ADO.NET、DataTables 等，请远离所有 ORM。

如果开发速度是您最大的问题，您应该学习 ORM 并走这条路。最容易推荐的 ORM 是 NHibernate。其他所有 ORM 都有明显的弱点。 NHibernate 适用于绝大多数项目，而其他 ORM 则更适合情景（取决于您的数据库设计、模型设计、敏捷性要求、遗留模式支持等）。所有 ORM 都有学习曲线，它们只是在不同的时间以不同的方式发挥作用。

【讨论】：

对于 LINQ to SQL（或 PLINQO），我没有任何学习曲线，开发速度也可以，你的意见是什么
这不是我使用 LinqToSql 的经验。如果您认为 LinqToSql 为您提供了两全其美的优势，请继续。无论如何，您最终可能不得不切换到 NHibernate。 LinqToSql 的功能很差，某些本应简单的事情在 LinqToSql 中可能非常困难。
你能提供任何将 LINQ 与 SQL 与 nHibernate ORM 进行比较的链接
此链接将引导您对 .NET ORM 进行大量比较：stackoverflow.com/questions/1377236/…
虽然对于当前的项目，我将自己限制在 LINQ to SQL 上（由于各种原因，例如时间限制、学习曲线），但我已经开始探索 NHibernate，我的第一印象是它非常好，我正在使用以下链接 summerofnhibernate.com 以及 nhibernate-in-action (book) +1 给你

【解决方案5】：

只是为了扩展@Developer Art，使用传统的存储过程方法可以让您将业务逻辑放入数据库中。通常你会想避免这种情况，但有时有必要这样做。更不用说您还可以使用这种方法在数据库级别强制执行约束和权限。这完全取决于您的要求。

【讨论】：

这样做很糟糕。它使理解代码、版本控制和重构 PITA 成为可能。
所以你说不应该把业务逻辑放到数据库里但还是推荐？
不，我不是这么说的——回去再读一遍答案。我不喜欢它，但有几次我遇到过需要将一些业务逻辑放入数据库的情况。您可以随心所欲地讨厌它（就像我说的，我个人不喜欢它），但有时这是最好的答案。业务规则可以采用触发器的形式 - 尝试在业务层中严格执行此类操作。
任何直截了当地说“这样做很糟糕”的人并没有考虑到所有的角度。理解代码并不难——无论代码在哪里，都应该有很好的注释和清晰的意图。版本控制可能是一个问题，但如果您的业务规则经常更改，那么您将使用规则引擎，而不是将它们埋在已编译的代码或数据库中。

【解决方案6】：

由于提到的限制，我想说只坚持即席/自定义查询和 ADO.NET，而不是去追求任何时髦的东西。此外，基于存储过程的 DAL 更快是基于概念的蹩脚参数，例如预编译的存储过程，但它们不是。他们所拥有的只是查询计划缓存。所以对存储过程的投资越少越好。我的建议是 ADO.Net 和从实体对象构造的自定义动态查询。

【讨论】：

所以您建议使用字符串连接在代码中构建 SQL 语句...？
是的，在提到的问题中这并不是一个很大的开销，因为他的应用程序并不是那么大，它总是可以保持简单
请阅读存储过程预编译神话。存储过程不会更快，从长远来看实际上是一种痛苦。它们也不是很变化的证明。像任何其他查询一样，存储过程具有查询缓存计划并且是预编译的。天真地说它们更快，因为它们是事先编译的。我有下面的在线书籍链接以获取详细信息msdn.microsoft.com/en-us/library/ee343986.aspx