最近都在看別人的文章，DongBlog的“常用的数据访问方式 ”感覺不錯，之前自己也想了解這方面的內容，正好今天看到，便收藏一下。原文如下：
我了解的常用的数据库访问方式（.Net环境）有以下几种：
1.直接使用.Net提供的各种DataAdapter或DataReader
2.使用数据访问控件（各种DataSource控件）
3.自己写的访问类（一般指的是自己封装后的DataAdapter或DataReader）
4.使用ORM框架
当然以上并不是包含所有的数据访问方式，但是常用的也就这几种。
数据访问的方式的选择很大一部分是依赖于构架的设计，相互之间也不一定是互斥的关系。比如说第二、三、四种方式其实都依赖于第一种，但是在某一定程度上作了封装。而且各种访问方式不一定有谁好谁坏的差别，更多的是适合于不适合。
下面详细说说我对几种数据访问方式的看法。
第一， 直接使用.Net提供的各种DataAdapter或DataReader。
这种方式相信大家都会。每一本讲.Net数据访问的书中都会这样告诉你：建立数据连接，建立Adpater或Command，打开数据库连接，执行数据访问，关闭数据库连接。这是ADO.Net的官方标准过程。
然而在实际生产中呢？
对每一个数据库访问都采用以上的过程吗？都写一大堆Try…Catch？连接字符串放在哪儿？数据访问代码放在哪儿？怎么实现数据源的可替换性？怎么测试？怎么处理并发？如果需求变了怎么办？更重要的是，对于每一次数据访问都要考虑以上问题吗？
显然，直接使用DataAdapter或DataReader不是一种良好的设计，要对以上过程在一定的程度上进行封装和抽象。这样也就有了以下几种数据访问方式。
第二， 用数据访问控件（各种DataSource控件）
微软为我们封装的数据访问控件。主要特点是快！在Vs.Net开发环境中，从数据库中拖一个数据表到WinForm或Web页上，自动就会生成相应的数据访问控件，包括相应的Select、Update、Insert和Delete命令。
数据访问控件和Vs.Net的配合可以说是完美，两者的结合把RAD发挥的淋漓尽致。基本上建立好数据库，点几下鼠标，你就可以有一个能用的用户界面了，甚至加上显示控件的AutoFormat功能，还能让你的数据界面具备一定的观赏性！所有的DataAdpater、DataReader、各种借口、容器、设计模式、构架、面向对象……统统忘了吧！甚至SQL语句你也可以不会！需要做的就是处理一个又一个的页面，拖放一个又一个的控件。当然有些复杂的东西还是需要稍作调整的，比如多表联合查询，不过也不要紧，DataSource还能结合Query Builder使用呢！好开心呀！
不过等等。当你吹着口哨，唱着小曲，身心愉悦的拖着控件的时候，头说了：某某需求变了，某某表也要变了。噢，天！我早就记不清那些控件用到那个表了！一个个的检查？我的WebSite里面有几十个aspx，上百个DataSource……。然后，当我刚刚改好，筋疲力尽的时候，头又说了：客户要求……，……，……，……。
如果从面向对象设计的角度分析一下的话，几乎所有的代码臭味都能用在这个系统上。简直就是反面教材呀！
那难道说这种方式也被无情的抛弃了，也不尽然。快有快的好处，以下情况适合采用这种方式（或者说，以下情况适合RAD方式）：
1， 原型系统：为了验证客户需求而编写原型，几乎不用考虑代码演化的问题，作为客户需求的说明和正式开发的参考为存在的。如果客户提出了新的需求或需求发生了变化，就编写新的原型系统。原型系统作为可编译、可运行的客户需求而存档。
2， 一次性的代码（Write Once，Use Once）：比如要求对数据库进行一些硬性的修改或维护的时候。这些代码执行了这一次操作之后，就失去了存在的价值。
3， 永远不会变的系统：很好理解。问题是，这样的系统，存在吗？
4， 作业：老师布置的作业，通常的特点是：简单、不会有大变化、注重结果、容易蒙混过关（^^）。
第三， 自己写的访问类（一般指的是自己封装后的DataAdapter或DataReader）
真真正正的面向对象的数据访问方法，看下面的图：
业务逻辑定义数据访问，DAL实现，有点类似于Adapter模式。业务逻辑和数据访问进行了良好的解耦合，数据访问层的实现依赖于业务逻辑，符合实现依赖于抽象的原则。
这种方法的好处很显然：高度解耦合、容易更改、适合团队开发。不过也不是没有缺点，那就是工作量要大一些，特别是当业务实体的类型较多时，可能总要重复的实现SELECT、INSERT、UPDATE、DELETE等。不过既然业务逻辑不依赖于数据访问，我们也完全可以变通一下，比如用代码生成加手工修改的方式，结合强类型的编译特点，修改起来还是比较方便的。
这种方法还有一个很重要的好处，解耦合的好处就是便于测试！进行测试时完全可以模拟一个数据访问层，单独对业务逻辑进行测试，甚至可以模拟各种数据库错误的情况！同时亦可以单独对数据访问层进行测试！
这种方式如果需要更换数据库的话，也是比较容易的，基本上一种数据库的访问可以封装一个DLL，根据系统的情况，部署的时候修改一下设置就可以了！
对了事务、特别是分布式事务等要求，可以在“统一的数据访问入口”这个位置实现。对于上层来说，是透明的。
这种方法是我最常用的方法，推荐！
第四， 使用ORM框架
这个就不说了吧？在园子里搜一下，肯定一大堆，慢慢看吧