0

我知道创建自定义数据访问层不是一个好主意，除非您：1) 确切地知道您在做什么，和/或 2) 有非常具体的需求。但是，我正在维护一些使用自定义数据访问层的遗留代码，其中每个方法看起来像这样：

    using (SqlConnection cn = new SqlConnection(connectionString))
{
    using (SqlDataAdapter da = new SqlDataAdapter("sp_select_details", cn))
    {
        using (DataSet ds = new DataSet())
        {
            da.SelectCommand.Parameters.Add("@blind", SqlDbType.Bit).Value = blind;
            da.SelectCommand.CommandType = CommandType.StoredProcedure;
            da.SelectCommand.CommandTimeout = CommandTimeout;
            da.Fill(ds, "sp_select_details");
            return ds;
        }
    }
}

因此，用法如下所示：

    protected void Page_Load(object sender, EventArgs e) {
    using (Data da = new Data ("SQL Server connection string")) {
        DataSet ds = da.sp_select_blind_options(Session.SessionID); //opens a connection
        Boolean result = da.sp_select_login_exists("someone");//opens another connection
    }
}

我在想，使用微软的企业库可以让我免于设置和拆除，即每次方法调用都连接到 SQL Server。我的这种想法正确吗？

4

3 回答 3

0

是的，它肯定会节省您的时间，但您会在性能和灵活性方面付出代价。

因此，创建自定义DataLayer也是获得性能和灵活性的好主意。

考虑到您在谈论遗留代码，我想它可以工作，我不会将它更改为现代（但性能较低）的东西，只是为了在我的代码中有一些新鲜的东西。

与您应该在遗留代码中实现的任何其他新技术相比，可靠、可行DataLayer是最好的选择。

简而言之，只有当你有真正的理由这样做时才改变它。我理解你愿意改变这些东西，因为总是很难理解别人写的代码，但相信我，很多时候不改变旧的遗留代码是项目的最佳选择。

祝你好运。

于 2012-04-05T21:13:22.657 回答
0

我过去非常成功地使用了 Enterprise Library，Enterprise Library 会向您隐藏一些混乱的细节，但本质上它会在内部使用与您的示例中演示的代码相同的代码。

正如@tigran 所说，除非存在基本问题，否则我不建议尝试更改现有代码库。

于 2012-04-05T21:19:41.370 回答
0

是的，默认情况下连接池将打开。应用程序域基本上维护一个连接列表，当您发出创建连接的调用时，它会从池中返回一个未使用的连接，如果它存在，则创建一个，如果不存在。

因此，当您的连接 cn 在 using 语句中超出范围并被处理时，实际发生的情况是它返回到池中，为下一个请求做好准备，并根据各种优化参数在那里徘徊。

谷歌 ADO 连接池的更多细节，那里有很多。

于 2012-04-05T21:21:00.857 回答