看到一些数据访问层一些方法写成如下两种形式: 
第一种形式;  
  public   DataTable   getDataTable(string   strSQL)   
  {   
      try   
        {   
            open();   //打开数据库连接  
            数据库,操作   
        }   
        catch   
        {   
              异常   
    
        }   
        finally   
        {     
             if(Conn.state=ConncetionState.open)   
               {   
                 Close();   //关闭数据库连接
               }   
        }   
  }   
 第二种形式:
public   DataTable   getDataTable(string   strSQL,string connString)  
 {
      DataTable dt;
     using (SqlConnection conn = new SqlConnection(connString)) 
    {
        //数据库操作;
return dt;

    }

}这两种形式都可以打开和关闭数据库并返回一个datatable,请问那一种形式会更好.如果我想写一个数据库访问层的类,我应该采用那一种形式.在性能上,那一种会更好.请高手指点.

解决方案 »

  1.   

    可是第二种形式是微软的PetShop开源的经典之作的呀
      

  2.   

    两种本质上是一个:
    using会在编译的时候自动产生try catch
      

  3.   

    第一种应该算是1.1的标准做法,
    第二种应该算是2.0的标准做法.个人看法.using 可以确保使用using的变量在程序出现异常时,也可以销毁对象.这个就是using的魅力所在.
      

  4.   

    感觉没仔细想,是在人云亦云。using (...)
    {
      try
      {
         ...
      }
      catch
      {
         ...
      }
    }这不是捕获异常吗?
      

  5.   

    try
    {
      using (...)
      {
         ...
      }
    }
    catch
    {
         ...
    }这不也是捕获异常吗?
      

  6.   

    再一开始看到楼主问“在性能上,哪一种会更好”,开始之所以没有回答,对于一个专业长跑运动员每个训练单元跑1000米和1001米没有什么差别,仅仅关注这个方面的性能差别在我们的经验中往往判断为这样的程序员是成事不足的,所以没有回答这个问题。using结构原本是为了及时、提前dispose一个对象的。在楼主这个问题中,它是结构化的,你不需要写close()代码。因为不需要程序员手工写close()语句,所以它是非常伟大的特性。
      

  7.   

    truelove12(IIF(str="李淫河","疯狗","败类")) ( ) 信誉:99    Blog  2007-1-17 8:28:22  得分: 0 第一种应该算是1.1的标准做法,
    第二种应该算是2.0的标准做法.个人看法.using 可以确保使用using的变量在程序出现异常时,也可以销毁对象.这个就是using的魅力所在.
      

  8.   

    using(IDisposable obj = new IDisposableImpl())
    {
    }==try
    {
    IDisposable obj = new IDisposableImpl();
    }
    finally
    {
     obj.Dispose();
    }虽然你表面上频繁的关闭打开链接  看似消耗系统资源 
    其实.net在幕后为你做了很多优化工作
      

  9.   

    看场合,不是固定不过只要能用using的我都用,习惯没啥说的
      

  10.   

    还是 IF ELSE 
    快```
      

  11.   

    我用的就是第一种。更灵活。第二种只是自动销毁了 SqlConnection conn ,那么其他的对象什么时候销毁呢?(你不会只用conn吧)
    另外呢,封装之后,多几行代码也没有什么累呀。你不会每次写项目的时候都写一遍这些函数吧。
      

  12.   

    其实之所以ms把ado.net设计成inmemory database就是不希望connection总是连接的状态,有可能的话会尽快收回连结池,所以频繁的开关connection是ado.net乐意看到的。而且在带宽急速提高的今天这也是有效分担服务器负载的好方法。
      

  13.   

    wanghu9999() ( ) 信誉:100    Blog  2007-01-17 12:09:09  得分: 0  
     
     
       在QQ群上的一好友这样说:分析:
    第一种:如果出现异常可以保证数据库连接的关闭,不影响其他使用
        缺点:各种资源需要自己控制释放
    第2种:资源使用完毕后直接释放
        缺点:第一种的优点
    推荐:综合  
    ————————————————————————————————————————说第一种的优点是第二种的缺点是不对的。使用using,即使不捕获异常,也会在异常抛出时关闭并且释放连接。
      

  14.   

    第二种只是自动销毁了 SqlConnection conn ,那么其他的对象什么时候销毁呢?(你不会只用conn吧)
    ——————————————————————————————————————————
    如果你需要提前销毁什么,那么就可以写在using里。例如:using (SqlConnection conn = new SqlConnection(connString)) 
    {
        .......
        using( SqlCommand cmd=new SqlCommand("select * from table",conn))
        {
             .......
        }
    }可见using是个工具,并没有不让你用(来销毁),只是你不用而已。但是正像这个局部变量cmd所显示的,什么是由销毁它又有谁关心呢?因为我们关心conn会不会因为程序员不小心少写了一个close()或者dispose(),所以才关心使用using来结构化它,让结构来保证逻辑一致。
      

  15.   

    其实之所以ms把ado.net设计成inmemory database就是不希望connection总是连接的状态,有可能的话会尽快收回连结池,所以频繁的开关connection是ado.net乐意看到的。而且在带宽急速提高的今天这也是有效分担服务器负载的好方法。
    ————————————————————————————————————————
    不对。这个说法没有区分逻辑连接还是物理连接。实际上仅对逻辑连接才需要尽快关闭,对物理连接需要尽量推迟关闭并且尽量复用。如果你使用一种数据库引擎的DBConnection的子类,它不自动支持连接池功能,你就不应该频繁开关connection,给你的编程建议与SqlCnnection绝对完全想反。
      

  16.   

    给你的编程建议与SqlCnnection绝对完全想反  -->  给你的编程建议与SqlCnnection绝对完全相反但是我的策略是自己写一个连接池管理类。例如我对SQLite.Net数据库就是这样的,它的SQLiteConnection 不支持连接池,尽管他根本不会像SQLConnection那样在DataReader的时候产生冲突,我仍然通过自己的连接池类(不过几十行代码)来创建连接。多个连接在多线程的时候至少多买了一份保险。
      

  17.   

    如果访问数据库后返回的是 SqlDataReader类型,在正常没有抛出异常情况下采用第二种形式能正常返回一个SqlDataReader类型数据流.而采用第一形式返回类型同样也改为SqlDataReader类型,可是最后返回的SqlDataReader类型却是一个null数据流.请问这又是什么原因.是不是第一形式在SqlDataReader类型数据流时候已经关闭了数据库
      

  18.   

    第一种能够捕获异常,肯定更人性化
    强烈支持第一种,这样就不夫对别人暴露出你的程序出错的问题,就会减少被人攻击的机会了。
    多几个代码无咩,多点用COPY就很快补回来的。
      

  19.   

    using (SqlConnection conn = new SqlConnection(connString))
    {
    .......
    using( SqlCommand cmd=new SqlCommand("select * from table",conn))
    {
    .......
    }
    }
    ==================using 也可以嵌套呀,长见识了。但是这么写不乱吗?
    用try只不过是多写几行代码罢了,但是不会乱。using嵌套的话,代码不见得少多少,相反,更乱了。
      

  20.   

    真有意思呀,故意写的那个“using(SqlCommand”是为了回答什么问题的,应该先搞清楚呀。如果你跟try来对比,有什么理由把这个考虑进来呢?考虑这个作为try的对比这不是故意歪曲需求嘛(如果你要考虑这个,即应该说明使用try的时候如何处理cmd,而不应该因为自己根本没有考虑到这个而说自己写的清楚,否则什么都不写不是更清楚嘛)。第二种与第一种的区别,不再于是否捕获了异常,我上面已经说过了。虽然第二种可以确保抛出异常之后也正常关闭了数据库连接,但是楼主的代码没有把读者被误导考虑进去,所以写的容易让人抓住根本与所闻问题毫不影响的东西来说事。它按说应该写为:第一种形式;  
      public   DataTable   getDataTable(string   strSQL)   
      {   
          try   
            {   
                open();   //打开数据库连接  
                数据库,操作   
            }   
          catch   
            {   
                  异常   
        
            }   
            finally   
            {     
                 if(Conn.state=ConncetionState.open)   
                   {   
                     Close();   //关闭数据库连接
                   }   
            }   
      }    第二种形式:
    public   DataTable   getDataTable(string   strSQL,string connString)  
     {
      DataTable dt;
      try   
      {   
         using (SqlConnection conn = new SqlConnection(connString)) 
        {
            //数据库操作;
            return dt;
        }
      }
      catch   
      {   
        异常   
      }   
    }这才不容易让不喜欢理解问题要点的人揪住所谓的“是否捕获异常”这个毫不相干的问题。如果我们把程序员都看作人,而不是机器,我们从人性的角度出发,就能看出地第种写法非常伟大。当有这种语法出现的时候,“忘记关闭数据库连接”是不可能发生的,除非根本没有打开连接,从而解放了程序员的责任。
      

  21.   

    我举双手支持sp1234例外说什么1.1或2.0的都是扯淡,这跟1.1和2.0完全没关系.说第一种优势是可以在出错的时候关闭也是扯淡,第2种也可以.说第2种会错了都不知道怎么回事的更扯淡,第2种比第一种还更知道~~~ ^_^其实这是个灵活性和方便性的选择,我的选择是可以方便的时候当然方便,需要领活的时候才放弃方便.所以我选择第2种,直到不得不用第1种的时候我才用第1种(这种情况极少~~~)
    不要小看第2种的少写一个Close的意义.尤其在代码质量不够高的时候.
      

  22.   

    using语句块只是保证清理垃圾,释放对象.而try语句块是异常处理,两码事情.
    我是组合一起用的.楼上oldmoon说using会在编译的时候自动产生try catch,好像没有这样吧?如果using语句块没有用try语句处理的话,出错时只是FrameWork抛出异常而以.不过有一句经典的话:越傻瓜式的就越没效率.using肯定会牺牲一点效率,如果一定要效率还是汇编好(^^)我的理解,不知对不对
      

  23.   

    Click the link to solve your problem.Good luck!