2012-04-05 85 views
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。我在这个想法中纠正了吗?

+0

自定义数据访问层绝对没有错。非自定义访问层的人写的不是他们正在做的事情,也不知道他们需要什么,现在有很多的错误。 – 2012-04-05 21:23:43

回答

0

是的话,肯定会节省您的时间,但你会在性能灵活性条款支付。

因此创建自定义DataLayer也是获得性能和灵活性的好主意。考虑到你在谈论遗留代码,我认为这很有效,但我不会将它改成现代(但性能较低)的,这只是因为我的代码中有新鲜的东西。

坚固,可行DataLayer是您应该在遗留代码中实现的任何其他新技术的最佳选择。

总之,只有当你有确实 seriouse原因做到这一点。我知道你愿意改变这些东西,因为总是很难理解其他人编写的代码,但相信我,经常不更改旧的旧代码是项目的最佳选择。

祝你好运。

0

我以前用过Enterprise Library的时候很成功,Enterprise Library会隐藏你的一些杂乱的细节,但实际上它会在你的例子中使用相同的代码。

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

+0

主要的是我想使用以前打开的连接,而不是使用数据读取器的数据集。当我通过代码工作时,我也注意到有很多实例将数据访问类在调用方法中反复重新实例化。从我的教学方式来看,这是一个不行的。 – Jim 2012-04-06 15:37:07

+0

啊,关于DataSets的好处。我总是使用DataReader并转换为类型。 – Phil 2012-04-06 15:48:10

0

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

因此,当您的连接cn在使用语句和get的处置超出范围时,实际发生的事情是它返回到池中,准备好接下来的请求并根据各种优化参数在那里挂起。

谷歌ADO连接池为更多细节,有很多内容。

+0

好的。谢谢。因此,通过使用诸如Microsoft企业库等数据访问的东西,我得到了什么好处。我宁愿使用ORM,因为我们的数据库模式已经非常牢固,但是这不是问题所在。 – Jim 2012-04-08 18:13:25

+0

连接池在使用ADO.net的任何一个下面,因此它不会影响选择DAL的体系结构 – 2012-04-08 20:58:05