一起谈.NET技术,重温数据库访问——故事篇

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

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

  市长在数据库岛上面建立了一个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和实体类。只是这一点说得并不是很详细,他们的优缺点说得也不多。

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

时间: 2024-09-28 05:30:03

一起谈.NET技术,重温数据库访问——故事篇的相关文章

重温数据库访问故事篇

本文想借用故事的方式来说一下ADO.net的工作方式.虽然现在都ORM了,但是了解一下ADO.net还是有必要的. 在茫茫的大海上有许多的岛,其中一个岛的名字叫做"应用程序岛".这座岛上商业非常发达,高楼大厦.店铺林立.但是岛的面积不够大,没有地方建立仓库.所以市长决定,把临近的一座小岛开发出来,专门作为数据仓库来使用,这座岛的名字就叫"数据库岛". 市长在数据库岛上面建立了一个MSSQL数据库,这样各个商场.超市就可以把自己的货物放进去了.两个岛相邻很近,为了便于

重温数据库访问——故事篇

  本文想借用故事的方式来说一下ADO.net的工作方式.虽然现在都ORM了,但是了解一下ADO.net还是有必要的.   在茫茫的大海上有许多的岛,其中一个岛的名字叫做"应用程序岛".这座岛上商业非常发达,高楼大厦.店铺林立.但是岛的面积不够大,没有地方建立仓库.所以市长决定,把临近的一座小岛开发出来,专门作为数据仓库来使用,这座岛的名字就叫"数据库岛".   市长在数据库岛上面建立了一个MSSQL数据库,这样各个商场.超市就可以把自己的货物放进去了.两个岛相邻很

一起谈.NET技术,数据库访问的性能问题与瓶颈问题

声明: 本文是一篇有争议的文章,甚至有可能是一篇争议非常大的文章,可能争来争去依然无法得到一个统一的意见. 场景 个别公司的技术决策者要求团队的开发人员在编写数据访问层的时候,禁止在程序中出现任何的SQL语句,禁止使用Entity Library,禁止使用NBear.NHibernate.IBatis.Entity Framework等ORM框架,只允许使用存储过程.试想一下,您的公司是否是这样子的?您的身边有没有这样的朋友,他们的公司存在这样或类似这样的情况吗? 矛盾点   对于开发人员来说,

一起谈.NET技术,Silverlight访问Apache服务器(Tomcat,Geronimo)中部署的Webservice

开发环境 Vs2010 . Silverlight4 . Java Jdk1.6 U 21 . Apache-tomcat-6.0.20 . Myeclipse8.5 . Apache-ant-1.8.1 . Axis2 . Geronimo-tomcat6-javaee5-2.2 下载地址: Apache-tomcat : http://apache.ziply.com/tomcat/ Apache-ant   : http://apache.ziply.com/ant/ Axis2 : ht

Java 实现连接sql server 2000(JDBC数据库访问例子)

server|访问|数据|数据库 刘金龙 04041222 ljlsunny@vip.sina.com   第一种:通过ODBC连接数据库 JAVA语言的跨平台的工作能力(Write Once ,Run Anywhere).优秀的图像处理能力(我相信现在没有那种语言可以超过JAVA在网络上的图形处理能力).网络通信功能.通过JDBC数据库访问技术等等,让我们谁都不可否认JAVA语言是SUN公司对于计算机界的一个巨大的贡献.笔者可以描述这样一个场景:有一天你上网完全可以不用IE 或者NETSCAP

Web服务数据库访问中间件的实现

web|web服务|访问|数据|数据库 摘要:本文分析现有的数据库访问中间件的现状,指出其中存在的问题,得出应用新技术的必要性.开发了一个基于Web服务技术的数据库访问中间件WSDBM,并以一个应用实例验证了该中间件的有效性.关键词:Web服务:数据库访问中间件:.Net 1  引言随着Intranet/Internet网络的迅猛发展,面向网络的分布式数据库成为支持Internet服务的关键,传统的数据库访问技术已渐渐不能满足分布式应用集成的需要.[1]利用新技术,研究和开发新的数据库访问中间件

【技术干货】缓存随谈系列之一:数据库缓存

本文作者:   乔锐杰    现担任上海驻云信息科技有限公司运维总监/架构师.曾任职过黑客讲师.java软件工程师/网站架构师.高级运维.阿里云架构师等职位.维护过上千台服务器,主导过众安保险.新华社等千万级上云架构.在云端运维.分布式集群架构等方面有着丰富的经验. 以下正文 ​ 我是个很懒的人,喜欢自己偷着练"葵花宝典",唯一可以看到我之前网上写的安全方面的文章,还是好几年前的事情了.公司最近来了一群美女,可是热闹了,写稿奖励美女,我老兴奋了. 说起缓存相关技术,老多了, memca

Java的JDBC数据库访问技术

在了解JDBC之前呢,我们可以先对ODBC做一个回顾,以便于更好的理解JDBC.看名字也知道这两个关系不一般,他们实现了同样的功能,为应用程序连接和操作数据库提供支持.所以,我们先从ODBC开始. ODBC ODBC(Open Database Connectivity)是开放数据库互连的简称,是一种使用SQL的应用程序接口.它是一系列的规范和对数据库访问的API.那么API+SQL就可以执行对数据库的操作.它是不依赖于DBMS的,即通过ODBC可以以相同的方式连接大部分数据库.它包括了应用程序

Wince MFC OLE DB SQLCE数据库访问技术(二):嵌入式目标平台创建本地数据库sdf文件

前言 上一节已经讲述了嵌入式目标平台上安装sqlCE,本章将介绍如何在目标平台上创建本地数据库sdf文件. 备注:博客中所有关于Wince MFC OLE DB   SQLCE数据库访问技术的文章都是基于SQL Server 2005 Compact Edition即 sqlCE 3.x     在讲述sqlCE之前,先来了解下,sqlCE优于wince 自带数据库的特点: 类别 对象 最大大小限制 存储 列名 128 个字符   表中的列数 1024 行大小 8060 字节   数据库密码 4