重温数据库访问——故事篇_.NET_编程开发_程序员俱乐部

本文想借用故事的方式来说一下ADO.net的工作方式。虽然现在都ORM了，但是了解一下ADO.net还是有必要的。

　　在茫茫的大海上有许多的岛，其中一个岛的名字叫做“应用程序岛”。这座岛上商业非常发达，高楼大厦、店铺林立。但是岛的面积不够大，没有地方建立仓库。所以市长决定，把临近的一座小岛开发出来，专门作为cangku.html" target="_blank">数据仓库来使用，这座岛的名字就叫“数据库岛”。

　　市长在数据库岛上面建立了一个MSSQL数据库，这样各个商场、超市就可以把自己的货物放进去了。两个岛相邻很近，为了便于运输，所以直接在两个岛之间建立了五座大桥。并且成了一个“数据访问池”的部门来专门管理这五座桥。

　　有一个叫command的家伙很聪明，觉得商机来了，于是他就成立了一家Command物流公司，专门负责两座岛之间的货物运输。物流公司成立了几个下属部门：Connection、DataReader。Connection负责与连接池的联系，申请大桥的临时使用权，并且还要提供车辆。DataReader负责装卸货物。

　　好了，万事具备只欠东风。物流公司成了好了之后就坐等客户上门了。不久来了一位客户，是岛上的一个书店，他们购进了一批图书，需要送到数据库岛的仓库里。

【添加记录的情况】

　　Command接到了这个任务很高兴，终于开张了。领导当然不能自己亲自去干活了，于是派出了明星员工cm007来负责这个任务。

SqlCommand cm007 = new SqlCommand();

　　Cm007从书店那里得到了指令（就是SQL语句）和货物，来到Connection部门。

cm007.CommandText = "";

　　Connection部门派出了得力员工cn007

SqlConnection cn007 = new SqlConnection();
cm007.Connection = cn007;

　　cn007开着车，带着cm007来到了大桥，由cn007和连接池联系，想要申请一座大桥的临时使用权。

　　cn007.Open();

　　连接池得到了这个申请之后，查看了一下大桥的使用情况，现在五座大桥都没有人使用，于是把001号大桥的使用权交给了cn007。这个时候，这座001号大桥就由cm007他们独占了，其他任何人都不可以使用。而且是按照独占时间来收取费用的。

　　一行人通过001号大桥来到了数据库，cm007把指令交给了数据库管理员开始交货。数据库管理员按照指令，把货物放到了指定的位置。办好之后cm007带着数据库的确认证明，从大桥返回到了应用程序岛。离开大桥后，cn007又给连接池发了一个申请。

　　cn007.Close();

　　连接池得到了这个申请后，收回了001号大桥的使用权，这样其他人就又可以使用这个大桥了。

　　cm007一行人来到了书店，把数据库管理员的证明交给了书店，客户很满意，这个任务也就完成了。回到物流公司交差。

　　cn007.Dispose();
　　cm007.Dispose();

　　command很高兴，首战告捷，以后的生意一定会很红火呀。

【提取（查询）记录，向上层直接返回DataReader的情况】

　　第二天，那家书店又来找command，要从数据库岛提五本书过来。又来生意了，太好了，于是又派出了cm007和cn007。不过这次和昨天不太一样，昨天是送货到仓库，今天是从仓库提货。这次还需要DataReader派装卸工来配合。

　　轻车熟路，cn007开着车带着大家来到了大桥，cn007申请了一座大桥的使用权，来到了数据库岛，cm007把指令交给了数据库管理员开始提货。不过这次却遇到了一点小问题，运输车的运载量的太小了，一次只能运一本书（一条记录）。可是这次却需要提五本书（五条记录），没办法，只好多跑几趟了。

　　带上一本书（一条记录），来到了书店，书店老板很高兴，这么快就到了呀，赶快卸货上架吧。咦等等，怎么只有一本书呀。Cm007只好解释，我们的车运载量太小了，一次只能运一条记录，不过速度还是很快的呀。

　　书店老板想了想，也凑合了，那你们赶快运下一条记录吧。

　　如是这般，折腾了五趟，总算把货物全都运完了。

　　“等等”，cn007说，“大桥的使用权还没有交回去呢。”于是大家又来到了桥头，把使用权交了回去。

　　最后回到物流公司交差。

【改进，向上层返回DataTable】

　　这回command可高兴不起来了。大桥是按照占用时间来收费的，这么来回折腾，大桥的占用时间明显变长了，这就增加了成本呀。另外现在汽油这么贵，来回折腾烧的可都是钱呀，就不能跑一趟多运点吗？

　　于是command把大家召集过来一起商量这个事情。cn007说，大桥这一段没有什么办法可想了，一次只能运出来一条记录，这个也不知道是谁规定的，我们也改不了。不过从桥头到客户那里我们倒是可以想想办法，我有一个朋友，DataAdapter，他们也许会有办法。Command听了也没有什么其他的方法，那就把DataAdapter请过来，一起商量一下吧。

　　第二天，DataAdapter过来了，也带来了他的解决方案。其实也很简单，他们公司可以提供集装箱（就是DataTable），在桥头等待，货物运到的时候由DataReader装到集装箱里，然后立刻返回运第二批货物。等需要的货物全都装完了之后，在开着集装箱运到客户那里。

　　SqlDataAdapter da007 = new SqlDataAdapter();
　　DataTable dt007 = new DataTable();

　　da007.Fill(dt007);

　　这样就节省了大桥的占用时间，节省了成本。到客户的这段路程，集装箱跑一趟就可以了，省油。

　　这个方案不错，command欣然接受。

　　过了几天，书店又要提一批图书，这次采用了集装箱的方案，果然大大节省了成本，客户也很满意，虽然一开始要等待比较长的时间，但是好在一次性就可以得到全部的货物。

【多种返回类型：DataRow、object[]、object】

　　有一天又发现了一个新问题，书店只要一本书。就一本书，也弄一个集装箱？太浪费了吧。怎么办？干脆直接用DataRow吧。实在不行用object[]。对于一条记录也足够用了。

【实体类开始登场】

　　于是物流公司的生意是越来越红火了。有一家大型超市也找到了command，希望能够为超市运输货物。这可是一比大买卖呀，command当然是很高兴。大家一拍即合。

　　一开始合作的也很愉快，但是过了几天出现了一点小问题。

【DataTable的缺点】
　　超市的老板找到了command，“你们的集装箱确实挺好，但是有一个小问题呀。他们的样子都是一模一样的，只能通过外面的标签来区分里面的货物，这个太不方便了，而且还容易出错，昨天本来想运一批‘微波炉’，结果标签写错了，写成了‘光波炉’。幸好发现的及时，否则就赔大发了。你们能不能想个好点的办法呢？”。

　　command心想：“你们把标签写错了，和我有什么关系呢？”不过客户就是上帝呀，得罪不起，还得想个办法解决一下。

　　于是又把大家都召集过来一起商议。只是这次并没有上次那么顺利，想了不少办法，但是都不理想。正在一筹莫展的时候，面向对象公司的推销员来了。

【实体类来了】

　　面向对象的推销员知道了这个问题后笑了（来生意了呀，哈）。“这个正是我们的优势呀，相对于集装箱（DataTable）的容易出错这个缺点，我们推出来‘实体类’，这种新型的集装箱，是根据不同的货物量身定做的，微波炉的实体类只能装微波炉，光波炉的实体类只能装光波炉，冰箱的实体类只能装冰箱……而且他们的外形也和独特，一眼就能看出来，很好区分。”

　　Command一听，这个好哇，正愁这件事情呢，太好了。“我们正在和一家大型超市合作，他们的货物有很多的种类，每一类都定制一个实体类，这样不就不会出错了吗？哈哈。快把超市老板找来一起商议一下。”

【不仅实体类来了，还带来了一批专门的装卸工人】

　　但是事实和理想总是有那么一点差距。以前用集装箱（DataTable）的时候，结构是一样的，DataAdapter只需要一种工人就可以完成装卸的工作，但是采用实体类之后，就必须按照实体类的各自的特点来找人。

　　能够给冰箱实体类装货物的工人，不能给电视实体类装货物，因为两种实体类的结构是不一样的。同理也不能给其他实体类装卸货物。这样就需要很多工人，一批工人专门装卸冰箱实体类，另一批工人专门装卸电视实体类……。

　　问题还不只这些，一开始超市大量提取CRT显示器，但是过了一段时间基本不提取CRT显示器的，因为被液晶显示器代替了。Command本来想去掉CRT的实体类和其装运工人，但是超市说了，虽然现在不怎么卖CRT了，但是还是有需求的呀。你裁掉了，下个月想运CRT显示器怎么办呀？

　　这样成本就又上来了。而且很可能养着一批工人，但是他们又没什么事情可干。

　　Command愁坏了，想要改回集装箱，但是客户又不同意，实体类很好用呀，你怎么可以改回不好用的集装箱呢？

　　这可怎么办？成本居高不下，快赔死了。

【“反射”登场了】
　　这时候又来了一个推销员。（怎么推销员这么多呢？）

这次是反射公司的推销员，他带来了一个叫做“反射”的东东，用了这个就不怕不同类型的实体类了，因为用了反射，同一批工人就可以给不同类型的实体类赋值了，不在需要向以前那样，不同的实体类需要不同的工人了。

　　太好了，这样就不需要那么多不同类型的工人了，成本又可以降低下来了。

?

　　故事就先到这里吧，再往下就应该说一说反射的效率问题了，但是这方面我还没有做过测试，理论上更是不清楚。所以就先不说了。

　　这个只能算是故事梗概吧，读起来很是干干巴巴的，没什么味道。俺语文没学好，文笔很差。这里表达的重点有两个。

　　一个是Connection和连接池的关系，Connection、Command、DataReader、DataAdapter他们的关系。我把Command看成了一个大的容器，在故事里是一个物流公司，其他的是下属部门或者是合作伙伴。

　　另一个是DataTable和实体类。只是这一点说得并不是很详细，他们的优缺点说得也不多。

　　目前就只想到了这些。后一篇就是代码篇了。

< type="text/javascript"> if ($ != jQuery) { $ = jQuery.noConflict(); }

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jyk/archive/2010/07/06/5717303.aspx