.NET下，你采用的是哪种方式进行数据操作？
进行数据库进行更新操作时，有许多种方式，你使用的是哪种？
这里假设一个数据库中有一张表，表名为Test，列为colID，colTest1,colTest2,colTest3。其中，colTest1,colTest2,colTest3为nvarchar(50），而colID为int;
一、数据适配器＋类型化的数据集
假设数据适配器名为da1,数据集为ds1，数据集类为ds;
方法1：直接操作的情况，利用Index来对Rows对象数组对象定位，此做法比较常见。
DataRow dr = ds.Tables[0].Rows[Index];
dr["colTest1"] = "test";
dr["colTest2"] = "test";
dr["colTest3"] = "test";
da.Update(ds);
方法2：当已知主键ID的时候，利用类型化数据集的特点，进行操作，这是MSDN中ASP.NET更新数据的教程中的作法（DataGrid的数据更新）
ds.TestRow row = ds.Test.FindByColID(id);
row.colTest1 = "test";
row.colTest2 = "test";
row.colTest3 = "test";
da.Update(ds);
方法3:修改与删除的时候,利用DataView做为中间桥梁,进行数据修改后,再Update.
从写代码的简便性上来说，上面的方法二略优于方法一与方法三，利用visual studio.net的代码提示功能，可以提高一点效率。
但使用数据集数据绑定后，使用Update操作数据库时,很容易遇到一些奇怪的情况,往往在进行频繁的Fill与Update的时候,数据集明明是发生了更改,但数据库中的值却没有发生更改或出现同步错误,而且解决数据库冲突,往往还要花费一些附加的代码,这些代码由于是在各个事件中填写,使得代码在观感上,更难于维护.并且大量的类实例的创建,对性能也往往为造成一些不可估计的冲击.Visual Studio.Net的数据适配器向导,往往又充当邪恶的角色,很容易勾引你使用它产生大量的垃圾代码.
二、数据适配器+非类型化数据集
方法1：建立一个空的DataSet数据集，直接用da.Fill(ds)，来填充ds，让它自动自成内部结构
方法2：继承DataSet类，然后手工填写代码,产生具体的实体类，再进行操作（如Duwamish的作法）
方法1是属于，准备工作比较简便，调用起来比较麻烦的，而方法2，是属于做准备工作比较复杂杂的，调用起来比较轻松的那种。两者的麻烦度差不多。
三、直接操作数据库
即建立一个Connection与Command，然后对数据进行操作，如果有必要的情况，使用参数化命令，当然本方式，也指使用存储过程进行调用的情况。
这种方法是最高效，粒度最细，控制最方便，使用上最安全的一种方法，但也是在code时最麻烦的一种，繁杂的CURD，可以让开发者彻底陷入数据访问的苦海，浪费大量的时间，极易让人产生烦燥情绪。
四、采用Application Data Block
方法一：直接使用微软提供的Data Block，利用SqlHelper类直接进行数据操作
方法二：也是使用微软的Data Block，但按照自己的需要作过一定的更改（比如，设置公共的Connection属性，以便不用每次都再写一遍）
相对来说，这类方法比直接操作数据库的方式要轻松一些，对于Connection的打开与关闭，几乎可以不作考虑，而且在采用事务进行数据操作时，编写代码将显得更为轻松。
五、利用O/R Mapping，进行数据库更新
方法1：全部是由自己手写代码或自己写的组件
方法2：采用商业组件，如Devexpress公司的XPO等
方法3：采用开源组件，如Nhibernate 等
这三种方法，都差不多，但从风险的角度考虑，方法2略优于另外两个方案，方法1需要大量的测试与验证，否则写软件时，不得不承担附加的风险，而方法3，如果.NET下的开源组件像JAVA中的那么成熟的话，是完全可以采用的，但目前在项目中使用Nhibernate，风险性还是比较大的。方案二中，由于有专业公司的维护，加上某些商业组件本身的成熟度，在一定的程度上可以减少风险。
采用O/R Mapping，无疑是最快乐的开发方式，但是的目前的阶段来说，目前在.NET下，采用O/R Mapping的方式写代码，还是要冒一定的风险，而且性能上，也是被人所诟病的。
六、利用代码生成器
方法一、完成使用代码生成器生成的代码或dll，对其进行调用。
方法二、仅利用代码生成器产生存储过程，经过测试后，然后自己手工写代码调用。
方法三、将代码生成的器的代码进行简单修改后，对其进行调用。
这可能是开发效率最高的方式了，但目前的代码生成器，在使用时，仍然是让人提心吊胆的，风险度大大高于O/R mapping的方式，很多情况下，许多代码生成器，实际上就是自动生成一个O/R mapping层，用于隔离数据持久化与业务代码之间的屏障。虽然目前有不少看起来很不错的生成器，但在使用时，还是要审慎一下才好。
以上所列出来的几种方法中，从最稳定的角度考虑，应该是三、四,如果几类方法间有所结合,我得出的如下结论:
(1) 综合从性能的角度考虑,在有数据绑定的情况下,采用数据适配器,进行数据填充与绑定,而数据库的更新则采用三或四的方法,相对来说,比较理想.
(2)如果采用O/R Mapping的方案,对于数据更新可以采用O/R的方案,但资料的查询等,还是采用SQL的方法进行,而不要考虑对象查询,可以大大地提高方案的可用性(该思想是progame告知的).
这篇文章,是顺手写的,在思想上有些什么不对之处,或者还有不完美善之处,希望大家能够不吝赐教.
这里假设一个数据库中有一张表，表名为Test，列为colID，colTest1,colTest2,colTest3。其中，colTest1,colTest2,colTest3为nvarchar(50），而colID为int;
一、数据适配器＋类型化的数据集
假设数据适配器名为da1,数据集为ds1，数据集类为ds;
方法1：直接操作的情况，利用Index来对Rows对象数组对象定位，此做法比较常见。
DataRow dr = ds.Tables[0].Rows[Index];
dr["colTest1"] = "test";
dr["colTest2"] = "test";
dr["colTest3"] = "test";
da.Update(ds);
方法2：当已知主键ID的时候，利用类型化数据集的特点，进行操作，这是MSDN中ASP.NET更新数据的教程中的作法（DataGrid的数据更新）
ds.TestRow row = ds.Test.FindByColID(id);
row.colTest1 = "test";
row.colTest2 = "test";
row.colTest3 = "test";
da.Update(ds);
方法3:修改与删除的时候,利用DataView做为中间桥梁,进行数据修改后,再Update.
从写代码的简便性上来说，上面的方法二略优于方法一与方法三，利用visual studio.net的代码提示功能，可以提高一点效率。
但使用数据集数据绑定后，使用Update操作数据库时,很容易遇到一些奇怪的情况,往往在进行频繁的Fill与Update的时候,数据集明明是发生了更改,但数据库中的值却没有发生更改或出现同步错误,而且解决数据库冲突,往往还要花费一些附加的代码,这些代码由于是在各个事件中填写,使得代码在观感上,更难于维护.并且大量的类实例的创建,对性能也往往为造成一些不可估计的冲击.Visual Studio.Net的数据适配器向导,往往又充当邪恶的角色,很容易勾引你使用它产生大量的垃圾代码.
二、数据适配器+非类型化数据集
方法1：建立一个空的DataSet数据集，直接用da.Fill(ds)，来填充ds，让它自动自成内部结构
方法2：继承DataSet类，然后手工填写代码,产生具体的实体类，再进行操作（如Duwamish的作法）
方法1是属于，准备工作比较简便，调用起来比较麻烦的，而方法2，是属于做准备工作比较复杂杂的，调用起来比较轻松的那种。两者的麻烦度差不多。
三、直接操作数据库
即建立一个Connection与Command，然后对数据进行操作，如果有必要的情况，使用参数化命令，当然本方式，也指使用存储过程进行调用的情况。
这种方法是最高效，粒度最细，控制最方便，使用上最安全的一种方法，但也是在code时最麻烦的一种，繁杂的CURD，可以让开发者彻底陷入数据访问的苦海，浪费大量的时间，极易让人产生烦燥情绪。
四、采用Application Data Block
方法一：直接使用微软提供的Data Block，利用SqlHelper类直接进行数据操作
方法二：也是使用微软的Data Block，但按照自己的需要作过一定的更改（比如，设置公共的Connection属性，以便不用每次都再写一遍）
相对来说，这类方法比直接操作数据库的方式要轻松一些，对于Connection的打开与关闭，几乎可以不作考虑，而且在采用事务进行数据操作时，编写代码将显得更为轻松。
五、利用O/R Mapping，进行数据库更新
方法1：全部是由自己手写代码或自己写的组件
方法2：采用商业组件，如Devexpress公司的XPO等
方法3：采用开源组件，如Nhibernate 等
这三种方法，都差不多，但从风险的角度考虑，方法2略优于另外两个方案，方法1需要大量的测试与验证，否则写软件时，不得不承担附加的风险，而方法3，如果.NET下的开源组件像JAVA中的那么成熟的话，是完全可以采用的，但目前在项目中使用Nhibernate，风险性还是比较大的。方案二中，由于有专业公司的维护，加上某些商业组件本身的成熟度，在一定的程度上可以减少风险。
采用O/R Mapping，无疑是最快乐的开发方式，但是的目前的阶段来说，目前在.NET下，采用O/R Mapping的方式写代码，还是要冒一定的风险，而且性能上，也是被人所诟病的。
六、利用代码生成器
方法一、完成使用代码生成器生成的代码或dll，对其进行调用。
方法二、仅利用代码生成器产生存储过程，经过测试后，然后自己手工写代码调用。
方法三、将代码生成的器的代码进行简单修改后，对其进行调用。
这可能是开发效率最高的方式了，但目前的代码生成器，在使用时，仍然是让人提心吊胆的，风险度大大高于O/R mapping的方式，很多情况下，许多代码生成器，实际上就是自动生成一个O/R mapping层，用于隔离数据持久化与业务代码之间的屏障。虽然目前有不少看起来很不错的生成器，但在使用时，还是要审慎一下才好。
以上所列出来的几种方法中，从最稳定的角度考虑，应该是三、四,如果几类方法间有所结合,我得出的如下结论:
(1) 综合从性能的角度考虑,在有数据绑定的情况下,采用数据适配器,进行数据填充与绑定,而数据库的更新则采用三或四的方法,相对来说,比较理想.
(2)如果采用O/R Mapping的方案,对于数据更新可以采用O/R的方案,但资料的查询等,还是采用SQL的方法进行,而不要考虑对象查询,可以大大地提高方案的可用性(该思想是progame告知的).
这篇文章,是顺手写的,在思想上有些什么不对之处,或者还有不完美善之处,希望大家能够不吝赐教.
