在 .NET（非 MVC）中访问数据的最佳实践答案

【问题标题】：Best Practices for accessing data in .NET (non MVC)在 .NET（非 MVC）中访问数据的最佳实践
【发布时间】：2012-11-21 20:18:02
【问题描述】：

我正在使用 .NET 3.5，并查看其他人完成的旧代码并尝试添加安全性并对其进行更新。

在 Web 表单项目中访问数据的最佳做法是什么？

目前我正在更改代码以使用 SQL 参数化，如下所示：

using (SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings[ConfigurationManager.AppSettings["defaultConnection"]].ConnectionString))
{
    using (SqlCommand myCommand = new SqlCommand(sql.ToString(), conn))
    {
        myCommand.Parameters.AddWithValue("search1", mySearchVar);
        ...

我知道 SQL 参数化很重要，但我看到其他人使用存储过程？他们是其他方式，最好的做法吗？

【问题讨论】：

.net 3.5，有什么理由不想使用EntityFramework？
我使用 LINQ to Entity Framework。
参数化本质上是存储过程的一部分
我不反对使用 EF，只是想要一些最佳实践。我现在正在阅读有关 EF 的信息，并且可能会使用它。
.NET ORMs - stackoverflow.com/questions/1377236/…

标签： c# asp.net .net

【解决方案1】：

如果不只是小型重构，并且您有时间重写数据访问层，请使用一些ORM：

NHibernate

Entity Framework

Dapper.NET (Stackoverflow ORM)

BLToolkit

【讨论】：

如果您需要快速 - BLToolkit。更少的功能，但它在性能方面击败了你所说的其他人。一年前使用它向 96 核数据库服务器每分钟发出数百万条 SQL 语句以进行 ETL 负载。
@TomTom 同意。也添加了 Dapper。
将 BLToolkit 与 T4 结合使用是我过去做过的事情，而且效果非常好，而且不必自己一开始就在代码中生成所有表格。

【解决方案2】：

使用 ADO.NET 没有任何问题。它是 .NET 中所有 ORM 解决方案的驱动力。

然而，.NET 开发人员似乎正在成群结队地加入 ORM 潮流。 ORM 只是数据访问工具箱中的众多工具之一。

在 2000 年初，ORM 席卷了 Java 世界。避免了存储程序。要么是 ORM，要么什么都没有。五年后，Java 开发人员意识到最好的解决方案同时使用 ORM 和存储过程，两者各有千秋。

使用最适合工作的工具。 ORM 可以自动化应用程序中的大部分 CRUD。存储过程适用于添加抽象、添加安全层和优化需要高性能的区域。

为工作选择最佳工具。

【讨论】：

+1：金句：选择最适合工作的工具！然而，选择最好的工具需要对问题领域（包括约束）和被评估工具的优缺点有充分的了解。

【解决方案3】：

Entity Framework 是一种“最佳实践”，也是 Microsoft 推动最多的一种。但是没有最好的数据访问方法。

在对 EF 和其他 ORM 的性能进行了一些糟糕的体验之后，我通常会完全避开它们，而只是手工制作数据访问代码或使用代码生成工具来输出为特定应用程序制作的代码。

另一方面，有很多不好的做法，您通过转向参数化来避免关键做法。

我个人认为现在存储过程没有任何意义，除非您打算完全使用它们 - 即防止在存储过程之外进行任何数据修改。如果是这种情况，它可以让您对可能对您的数据进行的修改类型感到放心。

所以这并不是一个真正的答案——因为真的没有答案——你的问题引发了一个巨大的讨论话题。是时候买些书了，或者忙于使用 Google。

【讨论】：