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


      本文想借用故事的方式来说一下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和实体类。只是这一点说得并不是很详细,他们的优缺点说得也不多。

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

  • 相关阅读:
    Nginx简单认识
    Redis简单入门认识
    用户体验报告——脉脉
    zine结构图
    猫眼电影原型图
    关于共享单车的一点思考
    用户体验报告——网易严选
    Zine和石墨文档竞品分析
    用户体验报告——石墨文档
    集合框架2
  • 原文地址:https://www.cnblogs.com/jyk/p/1771962.html
Copyright © 2020-2023  润新知