LINQ vs 存储过程 vs 内联查询答案

【问题标题】：LINQ vs Stored Procedures vs Inline QueriesLINQ vs 存储过程 vs 内联查询
【发布时间】：2011-11-28 14:54:35
【问题描述】：

我们是一个小团队，在非常紧迫的期限内使用 .NET 开发大型 Web 应用程序。我们正在使用多个数据库（每个客户端一个），因此我们的要求与大多数应用程序略有不同。数据库将仅用于此特定应用程序，因此它们是否与应用程序紧密耦合并不重要。主要的决定因素是开发速度、长期可维护性和安全性。我们正在考虑 3 个选项：

选项 1 - LINQ to SQL

我们都没有任何使用 LINQ 的经验，但我们一直在研究它，它似乎是一个不错的选择，而且学习起来也不难。在紧迫的期限内学习新方法值得冒险吗？

选项 2 - 存储过程

似乎维护多个数据库设置可能是一场噩梦（或者会吗？），并且由于我们没有专门的数据库开发人员，它可能会减慢在另一个环境中工作的开发速度。基本的 CRUD 查询将由代码生成器生成，这是一个优势。

选项 3 - 内联查询

这种方法开发速度最快，但我知道现在人们普遍反对硬编码查询，我担心从长远来看我们可能会遇到可维护性问题。基本的 CRUD 查询将由代码生成器生成。

如果我们缺少任何因素，请告诉我。哪种解决方案似乎最适合这个项目？

【问题讨论】：

“大”有多大，“紧”有多紧？我问是因为学习 Linq2SQL 并不难，如果你谈论的时间超过一两个星期，可能会缩短你的完成时间。但是，如果大是“足够大”，您可能会遇到一两个弱点，并且无论如何都需要其他东西。
截止日期是 3-4 个月，这个项目并不复杂或庞大，与我们过去的项目和团队规模相比只是很大。大概会有 30-40 张桌子。
虽然很难说，因为我不知道你的领域，但使用 NoSQL，你很可能在大约 10~15 个聚合根中对整个数据存储进行建模。可能甚至更少。我正在使用 RavenDB 构建的当前应用程序有 1 个主要聚合根和 2 个辅助根，它们更多地用于历史目的。

标签： asp.net sql linq-to-sql stored-procedures

【解决方案1】：

如果您的截止日期很紧，请不要尝试新事物。让开发人员在家里和业余时间学习 Entity Framework，并在下一个项目中尝试。同时做你最了解并成功使用过的东西。

如果内联查询在 DAL 程序集中解耦，那么内联查询也不错。

【讨论】：

同意这一点，我建议您看看 Dapper，它允许您使用更少的 ado.net 样板编写内联查询

【解决方案2】：

因为@Hasan Khan 涵盖了有关 SQL 的主要答案。我要抛出一个有点不同的答案。另一种选择是考虑使用 RavenDB，一个 NoSQL 数据库。它具有固有的租户数据库概念。根据您的要求，这听起来像是预期的目标。

【讨论】：